print gcode files to miniMaker (Page 7 of 16)

I spent some time with wireshark today and have a partial trace of commands.  Wifi still works poorly with XYZWare, there are often long delays between commands and sometimes the state is not properly refreshed.  However it is usable if you can put up with the unresponsivness of it all.

Here is what I have so far, you can see that almost nothing is ever returned from an individual command, instead we need to rely on status messages, and those can be unreliable.

-----------------
// clean nozzle

>XYZv3/query=a\n
<e:0\n
<j:9511,0\n    // idle state
<t:1,24,0\n

>XYZv3/action=cleannozzle:new\n

// loop looking for change in status
>XYZv3/query=a\n
<j:9536,51\n    // cleaning warming up
<t:1,24,0\n    // extruder turned off
..
<t:1,26,200\n    // extruder warming up to 200 deg
..
<t:1,191,200\n    // made it, or close enough
..
<j:9536,52\n    // ready to clean

//call 
XYZv3/action=cleannozzle:cancel
// or wait for
<j:9511,0\n    // idle state
<t:1,203,0\n

-------------------
// calibrate

>XYZv3/query=a\n
<j:9511,0\n    // idle state

>XYZv3/action=calibratejr:new\n

>XYZv3/query=j\n
<j:9535,40\n    // begin calibration
..
<j:9535,41\n    // ask to lower detector

>XYZv3/action=calibratejr:detectorok\n
>XYZv3/query=j\n
<j:9535,43\n    // calibrating
..
<j:9535,44\n    // ask to raise detector

>XYZv3/action=calibratejr:getdata\n
<calibratejr:{335,372,377,352,375,369,365,378,356}\n
<$\n

>XYZv3/action=calibratejr:release\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state

----------------
// home

>XYZv3/action=home\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state
..
<j:9534,5\n    // homing
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"y","dir":"+","len":"150"}\n

>XYZv3/query=j\n
// initially no value returned
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"x","dir":"+","len":"150"}\n

>XYZv3/query=j\n
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"z","dir":"+","len":"150"}\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state
..
<j:9532,30\n    // jogging
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"z","dir":"-","len":"150"}\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state
..
<j:9532,30\n    // jogging
..
<j:9511,0\n    // idle state


---------------------
// settings

>XYZv3/query=a\n
<o:p8,t1,c1,a+\n
<s:{"fm":0,"fd":0,"sd":"yes","button":"no","buzzer":"on"}\n

>XYZv3/config=autolevel:off\n

>XYZv3/query=a\n
<o:p8,t1,c1,a-\n

>XYZv3/config=autolevel:on\n

>XYZv3/query=a\n
<o:p8,t1,c1,a+\n

>XYZv3/config=buzzer:off\n

>XYZv3/query=a\n
<s:{"fm":0,"fd":0,"sd":"yes","button":"no","buzzer":"off"}\n

>XYZv3/config=buzzer:on\n

>XYZv3/query=a\n
<s:{"fm":0,"fd":0,"sd":"yes","button":"no","buzzer":"on"}\n

>XYZv3/config=restoredefault:on\n


-----------------------
// z offset

>XYZv3/query=a\n
<z:241\n

>XYZv3/config=zoffset:get\n
<241\n
<$\n

>XYZv3/action=home\n

>XYZv3/action=zoffset:up\n

>XYZv3/config=zoffset:get\n  // seems delayed, reading old value!!!!
<241\n
<$\n

>XYZv3/config=zoffset:set[261]\n

>XYZv3/query=a\n
<z:261\n

Here is a more complete list of wifi commands

-----------------
// clean nozzle

>XYZv3/query=a\n
<e:0\n
<j:9511,0\n    // idle state
<t:1,24,0\n

>XYZv3/action=cleannozzle:new\n

// loop looking for change in status
>XYZv3/query=a\n
<j:9536,51\n    // cleaning warming up
<t:1,24,0\n    // extruder turned off
..
<t:1,26,200\n    // extruder warming up to 200 deg
..
<t:1,191,200\n    // made it, or close enough
..
<j:9536,52\n    // ready to clean

//call 
XYZv3/action=cleannozzle:cancel
// or wait for
<j:9511,0\n    // idle state
<t:1,203,0\n

-------------------
// calibrate

>XYZv3/query=a\n
<j:9511,0\n    // idle state

>XYZv3/action=calibratejr:new\n

>XYZv3/query=j\n
<j:9535,40\n    // begin calibration
..
<j:9535,41\n    // ask to lower detector

>XYZv3/action=calibratejr:detectorok\n
>XYZv3/query=j\n
<j:9535,43\n    // calibrating
..
<j:9535,44\n    // ask to raise detector

>XYZv3/action=calibratejr:getdata\n
<calibratejr:{335,372,377,352,375,369,365,378,356}\n
<$\n

>XYZv3/action=calibratejr:release\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state

----------------
// home

>XYZv3/action=home\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state
..
<j:9534,5\n    // homing
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"y","dir":"+","len":"150"}\n

>XYZv3/query=j\n
// initially no value returned
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"x","dir":"+","len":"150"}\n

>XYZv3/query=j\n
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"z","dir":"+","len":"150"}\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state
..
<j:9532,30\n    // jogging
..
<j:9511,0\n    // idle state

>XYZv3/action=jog:{"axis":"z","dir":"-","len":"150"}\n

>XYZv3/query=j\n
<j:9511,0\n    // idle state
..
<j:9532,30\n    // jogging
..
<j:9511,0\n    // idle state


---------------------
// settings

>XYZv3/query=a\n
<o:p8,t1,c1,a+\n
<s:{"fm":0,"fd":0,"sd":"yes","button":"no","buzzer":"on"}\n

>XYZv3/config=autolevel:off\n

>XYZv3/query=a\n
<o:p8,t1,c1,a-\n

>XYZv3/config=autolevel:on\n

>XYZv3/query=a\n
<o:p8,t1,c1,a+\n

>XYZv3/config=buzzer:off\n

>XYZv3/query=a\n
<s:{"fm":0,"fd":0,"sd":"yes","button":"no","buzzer":"off"}\n

>XYZv3/config=buzzer:on\n

>XYZv3/query=a\n
<s:{"fm":0,"fd":0,"sd":"yes","button":"no","buzzer":"on"}\n

>XYZv3/config=restoredefault:on\n


-----------------------
// z offset

>XYZv3/query=a\n
<z:241\n

>XYZv3/config=zoffset:get\n
<241\n
<$\n

>XYZv3/action=home\n

>XYZv3/action=zoffset:up\n

>XYZv3/config=zoffset:get\n  // seems delayed, reading old value!!!!
<241\n
<$\n

>XYZv3/config=zoffset:set[261]\n

>XYZv3/query=a\n
<z:261\n

------------------------
// load/unload
// an error of 0x40000206 indicates no spool installed

>XYZv3/query=a\n
<e:0\n
<j:9511,0\n    // idle state
<t:1,22,0\n

>XYZv3/action=load:new\n

>XYZv3/query=a\n
<j:9530,11\n    // warming up
<t:1,24,200\n
..
<j:9530,12\n    // loading
<t:1,202,200\n

>XYZv3/action=load:cancel\n

>XYZv3/query=a\n
<j:9530,12\n    // loading
<t:1,202,200\n
..
<j:9511,0\n    // idle state
<t:1,201,0\n

// optionally call, if you did not cancel
>XYZv3/action=load:retry\n

>XYZv3/action=unload:new\n

>XYZv3/query=a\n
<j:9531,21\n    // warming up
<t:1,128,200\n
..
<t:1,199,100\n
..
<j:9531,22\n    // unloading
<t:1,199,100\n
..
<j:9511,0\n    // idle state
<t:1,92,0\n

// optionally call 
>XYZv3/action=unload:retry\n

------------------
// print

>XYZv3/query=a\n
<d:0,0,0\n
<e:0\n
<j:9511,0\n    // idle state
<t:1,26,0\n

>XYZv3/upload=MyTest.gcode,18688\n
<ok\n
><data>                // no newline
<ok\n
...
><data>                // no newline
<ok\n
>XYZv3/uploadDidFinish        // no newline
<ok\n
<ok\n

>XYZv3/query=a\n
<d:0,0,0\n
<j:9520,0\n    // check file format
<t:1,87,0\n
..
<d:0,1,2\n
<j:9505,0\n    // print in progress
<t:1,195,200\n
..
<d:0,2,2\n
<j:9505,0\n    // print in progress
<t:1,202,200\n
..
<d:69,2,1\n
<j:9505,0\n    // print in progress
<t:1,203,200\n
..
<d:0,0,0\n
<j:9509,0\n    // print ending
<t:1,194,0\n
..
// just prior to removing fillament spool
<w:1,PMP6QTH64R1093\n
<e:0\n
<f:1,199864\n
<j:9509,0\n    // print ending
..
// after removing fillament spool
<w:1,--------------\n
<e:1073742342\n
<f:1,-1\n
<j:9511,0\n    // idle state

Thanks for the kind words zheli. 

Can I ask what your build environment was, say ubuntu linux or windows 7 with visual C 2015, etc.  And any idea what the wifi issues where? 

I can compile my code on my ubuntu based windows subsystem for linux install.  That is a linux compatibility layer built into windows 10. And on the windows side Im using windows 10 and Visual Studio 2012 pro.

Oh, I suppose I should ask what branch you pulled, did you get the latest code or one of the older releases.

Wifi only sort of works, I am still working out how best to communicate using it.  Even if I perfect things on my end it is still a relatively unstable protocol, I would recommend using the serial port (usb) if you can make it work.

I was using the master branch, probably should checkout one of the version branch

Basically all I did is just to run `make` command in miniMoverConsole folder and of course it couldn't find `linux/wireless.h` file on Mac. So I just commented out that line and also changed autoDetectWifi to always return true. After that it was able to produce a executable `minimover` binary file. (At least I can get the help printout)

I removed the linux\wireless.h file and the code that depended on it, it was not being used anyway.  Now wireless should compile on the mac, although it is not really ready for serious use yet.

I have my program working 'ok' over wifi now.  I spent some time getting the action commands cleaned up, those are commands like load filament and calibrate.  Anyway previously they did not work at all on wifi and now the mostly work.  That is if you are lucky they work great and if you are unlucky then tend to lock things up.

I have a plan to improve things a bit.  If I rework those functions to poll for status (asynchronous) rather than block then at least the UI won't lock up while we wait for wifi to update things.

Anyway the core issue is deep in the firmware of the mini w (and most likely the rest of the wireless machines) the mini w can't seem to communicate with the wifi adapter and update its status reliably while it is performing some other task, the end result is that a query for status often fails (more often than it succeeds) and since we rely on status updates to detect a process is complete that can lead to the UI locking up for a very long time.

I may be able to make it act a bit better by carefully tuning how fast I poll for a status update.

One interesting thing I noticed when looking into this is that querying for all status (query=a) often returns a varied amount of data, that is one query may return the 'b' and 'z' parameters while another query returns 'X' and 'v'.  Both cases will return the terminating '$' character and what parameters are returned vs missing seems to follow no clear pattern.  All I can think is that the underlying firmware is struggling to keep up, probably because they are using a separate computer to manage the wifi network and that most likely is causing the communications issues.

Once again I want to point out that XYZWare is very inconsistent and often locks up for extended periods of times when communicating over wifi.  The core issue is that this protocol is not well defined or well implemented in the firmware.

Hello David,

I have been using miniMover 0.9 with Cura and it works like a dream! I have recently really gotten into modeling and printing threaded parts, but ran into a problem. When I tried to print a larger gcode file for a spike lugnut cover I modeled (41,000 kB), after a while it says process failed. I have heard that printing larger files is an issue and I was wondering if this was an issue you were aware of. Anyways, I have LOVED your miniMover utility and greatly hope that I can print large files in the near future.

carl_m1968,

If that were the case, wouldn't XYZware have had issue loading and slicing my model too? After trying to do this with miniMover I tested it with XYZware and it started printing the model (even though it didn't slice it well at all). It's almost as if miniMover 0.9 is timing out, but I'm no coding guru in the slightest.

Hi, David,

I take quick look at your code today, lots of efficiency issue, you should keep your code as efficient as possible, otherwise it is going to give you a lots of hanging, freezing, no response etc.

For example, you have void MainDlgUpdate(HWND hDlg) that you wrote in memo that is running 2x per second, but you run const XYZPrinterInfo *inf = xyz.getPrinterInfo(); in it, do you really think any of those information going to change every half second?

Also you are trying to check if ssid and password changed and try to update the value if changed. Didn't you already updated that when click autoconnect?

I did not spend enough time to fully understood your code, so the above point may be wrong, my point is, if some code need to run again and again like 2x per second, make it do as little as possible.

I think you did really good job in design this app, and wish you best luck with the wifi stuff.

Thanks for your notes, these are good ideas. 

On the first one I already changed things around so that I am only polling for an update on the printer status once every 2 minutes or so, and then I added in a flag that can be set to force an update if someone edits the z-offset or any of the other settings that depend on the printer status.  That code is in the head branch but has not been released yet.  I also drive all of this via timers now so that the message pump has time to spin between editing a value and polling for the change.

On the second one that is working around an issue in win32.  I only want to update the value stored in the text box if it changed, otherwise I will block the user from being able to edit.  The test is very fast (C is very efficient compared to C# when it comes to strings) so it is not expensive.

As for blocking, the real issue is that every communication with the printer takes a long time to complete and my code is not well written to deal with that.  That is what I am working on now, splitting up the code even more so I can update the UI while waiting for communication wit the printer to complete.  With the USB connection things were fast enough that you could usually get away with my setup, but wifi is 10x slower and that pushes almost all communication into the 'too slow' bin.

I have been a C++ developer for 20 years now, but in truth I hardly ever do windows UI's and it is not one of my strengths at all.  That is part of the fun of this project, forcing myself into areas of code that I usually never get to play with.

Read more about WaitForSingleObject(ghMutex, INFINITE), my guest is the infinite is causing the trouble. There are work around to avoid use INFINITE and allow you do other things while waiting for response.

I think you can at least give a more specific timeout to most of the WaitForSingleObject that expect response within minutes, otherwise your app may hung whenever miniMaker loss power or reboot or when you have poor wifi signal for whatever reason. You can pop a error message which make debug less problematic.