print gcode files to miniMaker (Page 4 of 16)

I made some progress on adding in support for controlling a printer over wifi.  I have a rudimentary socket class that works, but could use a bit of help. And I have the basics stubbed in for the UI work. I still have a long way to go, and I'm not very optimistic that I can get the socket code to work right without having a machine to test against, but we will see.

Here is an early alpha version of miniMover 0.9.  This is laying the groundwork for printing over wifi. 

I have extended things so you can setup the wifi network, and have the code in place to query the printer ip so we can connect back to it after we remove the usb cable.  I also have a rudimentary soccet class going that may or may not work, but it is not currently hooked to anything.  Finally I filled in the rest of the options, like changing the name of the printer and adjusting the language and power saving options.

Still to do is to stash off information on the printers network into the registry (or a local text file), to load that information back up and populate the machine drop down, and finally to switch over to my socket class when a wifi connection is selected.

What I really need right now is someone with anything other than a miniMaker to test this out over usb and try adjusting all the settings and tell me how it goes.  If you can, create a debug.txt file in the same directory as the miniMoverUI.exe file before running any tests and send me the resulting file.  You can post it here, or email it to david.tucker at goliathindustries dot com.

I really need to get some data back from a machine that is configured to talk over wifi so I can see how to parse the return data.  Right now I'm mostly guessing at the format.  Any data would be a huge help.

Finally, this is completely untested, it could crash or blow up in any number of ways (but won't hurt your computer).  Keep a copy of 0.8 around if you need this to work reliably.

David,

If I gave you access to a machine that was on my network with the printers, would that help you debug?

Where are you from?

email me at glennemay at g m a i l . c o m

I got a "da Vinci miniMaker" + red edition. It will not be recognized by the program. I use an usb 2.0 connection that lives as com12 in device manager and I can connect to it via xyzware.

Can you create a debug.txt file and place it next to the minimover exe, then try to run the program.  That will log out any attempts I make to communicate with the machine.  Maybe it will give me a hint about what is going wrong.  You can post the output here, or email me at david.tucker at goliathindustries.com

Also I attempt to auto detect the port, but it is possible that I am latching onto the wrong device.  Can you manually choose com12 in the minimover program and see what happens.

Finally there are some known issues with the last few versions of minimover.  You may have more luck by going back to version 0.5.0 from here https://github.com/reality-boy/miniMover/releases. 

I have some bug fixes checked into github, I'm hoping to make a new release here soon.  My hope is to spend a few days doing some serious testing to make sure everything is working well before I release it.

I'm just wrapping up version 0.9 and hope to have it up to you by tomorrow.  In testing it out I realized that I have had a lot of long standing bugs in my code. 

One big one was in version 0.6.0 I lowered the communications timeout from 10 seconds to 0.5 seconds.  That was much too aggressive and can lead to regular failures.  I'm bumping that up to 5 seconds, but keeping it at 0.5 seconds when querying the z-offset  Apparently the pro 1.0 does not support that call.

Another was in the 0.9 alpha I posted a while back, I goofed up a call that was suppose to write a repeating byte pattern to file but instead started reading random blocks of memory.  Of course that lead to a nasty crash that was hard to track down.

Finally I managed to goof up the settings by being too agressive in pushing the last known state from the printer.  Basically you could not edit some settings because the state was constantly being updated.  I have this cleaned up by caching the current state and only updating if the setting changed.

In addition I have put in a lot of work to split out the maintenance routines so they can be run in loops rather than blocking.  I have everything split out but don't yet have the loops in place.  Once that is in place you will be able to see the hotend heat up and see the sub sate change when loading filament or doing other maintenance.

I also put more time into wireless. I have my wifi and serial classes deriving from a generic serial base class.  That will make it much easier for me to switch back and forth between them when I get ready to implement wifi support.

Anyway I hope to get this out to you soon, once I get some more testing behind me.  I usually only have time to work on this a few times a week for 45 minutes or so.  With so little time I have been guilty of pushing changes with almost no testing, and sadly some bugs have crept into the works.  I'm hoping that 0.9.0 will be a stable release that will work for some time.  In the meantime version 0.5 is very stable and worth checking out.

good update, i got a vinci pro and notice that most commands wont work on it.

i want to make octopi like base for my vinci pro and this program is very cool.

also cant believe this records temps better than xyzware does lol

Let me know if 0.9 works better with changing parameters on the pro, it should be more stable.  If it does not work then could you give me a list of options that don't work? 

I have often wondered if the options work with printers that already have a setting menu on the printer, or if they only work with the mini and micro printers that lack a LCD.

Very interesting.  I guess it makes sense that they would not duplicate the on screen menu.  Although it seems short sited to force you to use the printer menu, what if the display went out or you can't read the text, etc. I wonder if that is the case for all the other printers.

I have tried to spoof things in XYZWare so that I can see how it would look with other printers, but have only had very limited success. It would be nice to see what they do for each printer.  Maybe I will code up an arduino to look like a printer.

While I was waiting for my mini w to come in, I decided to try porting my code over to linux/mac.  After a days work I managed to get almost everything to compile, everything but the networking/serial code that is...  Anyway I'm going to spend some time cleaning up the effort and then check it in.

The only problem is that I'm using the windows 10 linux subsystem and I can't get that to allow access to my serial port.  So I can compile but can't test.  I guess I need to dig out an emulator of some sort.  Anyway I guess I'm burning the candle at both ends now

David,
before dealing with all the plattform-specific details... Have you thought about porting minimaker to java? Getting it to run on win/linux/mac would be way easier. I'm using my java based application for a while now (for uploading files, loading/unloading filament, zoffset etc).
Willing to offer sources as a starting point :-)