201

Re: print gcode files to miniMaker

Spent some time cleaning up wifi, I think there is hope in the far off distance for this.  I had misunderstood how select worked, now it should work better.  I was able to remove all the sleeps in the xyzv3 lib and in the miniMoverUI project.  And with some creative extensions of the delay routines I think I have managed to stabilize things better.

Anyway there is no way to know if I got it right other than to obsessively test every possible permutation over wifi.  Now I'm off for a busy week of testing.

202 (edited by david.tucker 2018-09-26 05:36:16)

Re: print gcode files to miniMaker

More progress, I managed to clean up the error handling a lot and now the UI is much less likely to halt unexpectedly. 

There is still an odd error every once in a while where the UI is responsive but won't take focus.  I'm sure it has something to do with bailing on a sub dialog inappropriately, however I can't find any issues.

Also if a sub dialog action fails there is no obvious indicator that it failed.  I need to force a failure status all the way back down to the UI.

Finally things seem to be behaving well when I don't have a connection at all, or the connection gets broken mid task.  I still have loads of testing to do but we are on our way for the 1.0 release.

---

The big task still left to do is to split the file conversion routines apart.  I made a lot of progress on cleaning up the routines but I still need to keep track of state and run a state machine over the whole conversion process.  This is the last major holdup on the UI responsiveness. 

Also I need to extend the routines so that I auto convert a .3w file if you try to send the wrong version to a printer, although this is really only a problem for me since I have 3w files formatted for every known printer file.  Most users are unlikely to keep there files in 3w format, and even if they do they are unlikely to have a mix of different printer models.  And even if they do again there are only a few models that can accept the exact same gcode without the print failing.

203

Re: print gcode files to miniMaker

Quick question, how long do you think is a reasonable time to establish a connection to a printer on the local wifi network. 

I had a 5 second timeout while waiting to connect to a printer, however 5 seconds is an eternity in UI land.  I just lowered it to 1 second but I suspect that is still at least 2x longer than I really need.  In theory I should be able to establish a connection to a local printer in 10 ms or less, less than 200 ms if you tunnel across the internet to another country.  However I'm not sure how responsive the wifi adapter from XYZ is so I don't want to push this too hard.

204

Re: print gcode files to miniMaker

For my D7 running on NanoDLP in a Pi it can take up to 3 seconds sometimes before my network sees it in the other room. You also have to allow time for the subsystems in the controller to fully boot.

Printing since 2009 and still love it!
Anycubic 4MAX best $225 ever invested.
Voxelabs Proxima SLA. 6 inch 2k Mono LCD.
Anycubic Predator, massive Delta machine. 450 x 370 print envelope.

205

Re: print gcode files to miniMaker

Is that time from boot up or time since hitting the connect button. I’m not that worried about waiting for the controller to power up.

206 (edited by carl_m1968 2018-09-26 13:57:35)

Re: print gcode files to miniMaker

david.tucker wrote:

Is that time from boot up or time since hitting the connect button. I’m not that worried about waiting for the controller to power up.


That's the time before it shows in my routers table so I can see what IP it is assigned.

But again this is a Pi, not a Da Vinci.

Printing since 2009 and still love it!
Anycubic 4MAX best $225 ever invested.
Voxelabs Proxima SLA. 6 inch 2k Mono LCD.
Anycubic Predator, massive Delta machine. 450 x 370 print envelope.

207

Re: print gcode files to miniMaker

Managed to clean up a lockup when communicating over usb.  I had some timeouts running too long, and I did not have any timeout when writing, so if the usb hiccuped the whole UI would lock up.

And all of the setup commands seem to be working on usb, as are the file convert commands.  I still need to run a test print to verify it works.

Unfortunately I can't seem to set the wifi card up right now.  It is not clear if I have a programming error or if my mini w is finally dying.  Anyway I need this up and running before I can make a release.  I'm thinking if I can verify that everything works on usb I will do another release without worrying about wifi just yet.

208

Re: print gcode files to miniMaker

Fixed the wifi settings, the trick is to disconnect from wifi long before you attempt to update the settings.

209

Re: print gcode files to miniMaker

Somehow I messed up printing (well uploading a file), I'll try to clean it up tomorrow and get the command line tested.  Maybe I can have a new release in a few days.

210

Re: print gcode files to miniMaker

Fixed up file printing, turned out my write timeout was too short.  Also fixed a bug that stopped convert file from working on the command line.

Still need to do  more complete test of the command line, I think printing is not updating the status correctly.

211

Re: print gcode files to miniMaker

Someone found a bug in the linux port, the code that is suppose to buffer the incoming data into lines is broken.  I'll try to track it down.

212

Re: print gcode files to miniMaker

Fixed the linux build, I think it has been broken for a while now.  I was using memcpy to shift a string down in a buffer, but apparently that is not guaranteed to work on linux.  Now I shift by hand and everything is working properly again.

213 (edited by david.tucker 2018-10-04 06:45:48)

Re: print gcode files to miniMaker

So as far as I know I'm ready for a 0.95 release.  This will be the last major release before the 1.0 release when I consider this functionally complete (but not necessarily finished).  All I need to do for the 0.95 release is to continue to test everything.

For the 1.0 release I could potentially add the following features:

  • Finish up wifi support, it works now for some functions but I'm positive it will fail in some situations

  • Update status when printer is heating up for any reason, right now I just pause for a long time (but no longer block)

  • Move setting of wifi parameters into the state engine, this can block for up to 20 seconds.

  • Move misc functions into state machine, they don't usually block at all, but it would be best to be better prepared just in case they do.

  • Pull status while spinning in state machine.

  • Merge state machines from many one off machines to single master machine, I'm not convinced this is the right thing to do.

  • Split file conversion into pieces so we don't block on long file conversions.  Most files convert in less than a second but it is possible to block for 10-20 seconds on a huge file.

  • Hide optional settings pane on UI, possibly blocking access if printer does not support the optional commands

  • Work out a better way to auto detect serial port on Linux

  • Work out how to pull wifi config information on Linux

  • Add wifi config support to command line, and language, etc.

  • Check return status of state machine in UI.  I already handle this right in command line

  • Better status updating in command line, right now it can go silent for too long.

More long term features include:

  • Support for poking at the scanner, I don't know if I can ever make this work completely, but maybe I can provide the low level logic for another program to use.

  • Support driving the laser, this will probably require me getting a laser at some point.  Sounds nice but they are not cheap and this is just a hobby.

  • Support for the 1.x and 2.x machines, I have part of the protocol worked out but need hardware to test against to make it really work.  I'm hunting for a steal on a 1.x machine, if you have one you want to let go of let me know.

  • Support for the new color machines, maybe someday.

  • Support for big endian architectures, if I can find anything to compile against

  • Support for Unicode fonts in the UI

  • Support for string localization everywhere

  • 64 bit support, is this really needed?  I should at least compile on 64 bit even if I can't handle 4GB files.

Another long term project would be to create a wifi to usb bridge, much like the wifi bridge that XYZ now sells.  The idea being that you could use a raspberry pi zero w to put your printer on the network.

Finally adding in support to octoprint would be great, although that would probably take a lot of work.

214

Re: print gcode files to miniMaker

I spent some time last night trying to get everything to compile in Unicode mode and in 64 bit. Unicode is a bit of a lost cause, I’ll save that for later but I can compile in 64 bit now. I’m not properly supporting files larger than 4 gigabytes, I don’t know how important that is. My mini maker certainly can’t support anything that large.

215 (edited by david.tucker 2018-10-03 07:03:05)

Re: print gcode files to miniMaker

I finished converting everything to 64 bit (still need to test it) but I'm not sure this even makes sense.  The file format itself is not 64 bit compatible.  There is a small speedup from using native register sizes, and potentially this now better supports using the full 32 bit (4 GB files rather than just 2 GB files).

Anyway I'm going to sit on it and think it over and maybe some clarity will come in the morning.

I also made the low level usb/network protocols 64 bit compatible, however that really does not make sense since the underlying api's are limited to much smaller outputs.  At least my buffered read/write code could handle the larger address space, but the buffers are hard coded to be relatively small so that seems like a waste as well.

216

Re: print gcode files to miniMaker

Gave up on 64 bit, I kept finding potential failures

217 (edited by pentaxxx 2018-10-04 06:28:16)

Re: print gcode files to miniMaker

I have 3in1 Pro and also laser module, so if you need, I could help you with testing.

Currently I'm working on mods, repairing ThreeDubber bugs (do not work on some OS's with different regional settings) and adding some additional functionality to recognize more variants of slicer sources (slic3r, cura, XYZWare). Also found FXX model of printer, seems to be universal model for .3w demo files.

I also build cartridge reseter (only found, that source .ino files need some changes for my firmware/Pro model versions). Only possible to reset to 120m maximum and change serialnumber and used length.

218

Re: print gcode files to miniMaker

Thanks for the offer and it sounds like your making good progress.  That is interesting about the FXX model number, I will give it a try.  It would make file conversions a lot simpler for sure!

For the 3in1 Pro, the most useful thing would be to get a capture of the communication while you are initiating a laser print, or scanning an object.  I have a list of potential scanner commands her https://github.com/reality-boy/miniMove … 0notes.txt and there is a laser place object command and power command that may be laser related, I just don't have an example of how they may be used.

There are plenty of serial port capture programs, but I have had good luck with a program called device monitoring studio, they have a free demo mode that works good enough. https://www.hhdsoftware.com/Downloads

219

Re: print gcode files to miniMaker

I will try to use port monitor software.

Currently I have problem to connect to COM port on my PC (Windows 7 x64 + Minimover version 0.9).
I was able to connect from another slimbook with Windows 10 Pro x64.

Probably problem of drivers/more printers connected/.......etc.

I will compile latest version today and I will try to debug, what's wrong.

220

Re: print gcode files to miniMaker

pentaxxx wrote:

I will try to use port monitor software.

Currently I have problem to connect to COM port on my PC (Windows 7 x64 + Minimover version 0.9).
I was able to connect from another slimbook with Windows 10 Pro x64.

Probably problem of drivers/more printers connected/.......etc.

I will compile latest version today and I will try to debug, what's wrong.

Try adding a debug.txt file next to the minimover exe, I will dump debug info into that which may help us find the issue.

I'm just about ready to make a new release that has a lot of small bug fixes in it, and a major rework of the architecture.  I think I will be able to push it up tonight.  That may fix whatever is wrong with the serial port, or maybe not.  If nothing else it has much improved data logging to the debug.txt file.

221 (edited by david.tucker 2018-10-06 04:35:57)

Re: print gcode files to miniMaker

http://soliforum.com/i/?ZkPxM1i.png

Just posted the 0.9.5 release, this should be feature complete with 0.9.0 but more stable and less likely to lock up.  Also it has an initial pass at WiFi, improved UI, compiles under linux/mac and many small bug fixes.  Let me know if it works for you or not.

Linux support should mean you can compile it on a Raspberry Pi as well, although I have not tried that yet.

222

Re: print gcode files to miniMaker

It's a new record, I found 2 bugs 5 minutes after releasing the code.  Anyway I updated the exe's so download everything again if you already grabbed them.

One bug is trivial, I forgot to bump the version number, but the other caused parsing of some json values to fail, mostly that only effects the mini and nano series.

223

Re: print gcode files to miniMaker

I know about debug.txt.
I'm able to print with XYZWare pro and XYZ printing. Arduino 1.8.5 can detect board on COM port, but minimover can'see printer.

I think it is any trivial bug of my Windows installation / serial.cpp library. As I told on my W10 minibook it seems to be working (at least it is able to get status of printer and serials and ....).
I tried to disconnect all USB devices excluding mouse and keyboard.

Here is a basic log (from v0.9b compiled yesterday - versions from 3.10 and 4.10):



Log started Sat Oct 06 11:05:21 2018


0000.02 SerialHelper::queryForPorts(XYZ)
0000.02 SerialHelper::queryForPorts failed to find any ports
0000.03 XYZV3::setStream(0)
0000.03 MainDlgSetStatus(not connected)
0000.03 SerialHelper::queryForPorts(XYZ)
0000.03 SerialHelper::queryForPorts failed to find any ports
0000.03 MainDlgUpdate()
0000.03 MainDlgSetStatus(not connected)
0010.04 MainDlgUpdate()
0010.04 MainDlgSetStatus(not connected)

224 (edited by david.tucker 2018-10-06 18:28:19)

Re: print gcode files to miniMaker

I put in a small change to the serial port code that may make it work better with your situation.  Let me know if it helps.

If it does not help then please download this project http://www.naughter.com/enumser.html, in the zip file is a precompiled dos exe that will use every known way to enumerate the serial ports on your computer.  Give me a dump of the output and let me know what port matched your printer and I will add support for whatever call actually works.

If nothing works you can specify the port in the command line version of minimover with the -d command, so minimover -d 6 -s will dump the status for anything found on com port 6

Oh, and if you have not tried it yet, try moving the printer to a different usb port.  Sometimes that can trigger windows to reinitialize the drivers, and that may clean up whatever is wrong on your system.

225

Re: print gcode files to miniMaker

I was successful with Simplify 3D (they have file encoding to .3w and upload to XYZ printer implanted into app).
So I was more sure, that problem is not in drivers.

I cleaned registry, COM arbiter, removed all CH340 and XYZ drivers etc.

Still not working, but cli version of minimover give me output with no problem.
If i put device com port, I had no problem to get -r or -s status report.
So problem seems to be in autodetect routine or registry search or something like this.
It seems, that it could be simply solved by adding combobox with manual COM port selection into UI version of minimover :-D .