print gcode files to miniMaker (Page 10 of 16)

CreateFile method reports
COM3
QueryDosDevice method reports
COM3
GetDefaultCommConfig method reports
COM3
Device Manager (SetupAPI - GUID_DEVINTERFACE_COMPORT) reports
Device Manager (SetupAPI - Ports Device information set) reports
COM3 <XYZprinting, 3D Printer da Vinci 1.0 Pro 3in1>
EnumPorts method reports
COM1 <Local Port>
COM4 <Local Port>
COM3 <Local Port>
COM7 <Local Port>
COM5 <Local Port>
COM6 <Local Port>
COM8 <Local Port>
COM9 <Local Port>
COM10 <Local Port>
COM12 <Local Port>
COM13 <Local Port>
COM11 <Local Port>
COM15 <Local Port>
COM17 <Local Port>
COM18 <Local Port>
COM30 <Local Port>
WMI method reports
COM3 <XYZprinting, 3D Printer da Vinci 1.0 Pro 3in1 (COM3)>
ComDB method reports
COM3
COM4
COM5
Registry method reports
COM3
UsingGetCommPorts method reports
CEnumerateSerial::UsingGetCommPorts failed, Error:126

So it is becoming clear to me that the only way to get WiFi to be remotely stable is to carefully control how often you send a message to the machine.  And the only way to control that is to have everything run through a state machine so the calling program is not tied up in knots worrying about timing.  So to that end I'm moving the rest of the commands over to my state machine.  This will clean up the interface a bit, and eliminate the need for sleeps in the command line or variable timer intervals in the UI making the whole thing a lot more user friendly.

Anyway it will take some time to get this carefully moved over, but hopefully it will lay the ground work for me adding in logic to hold off on communicating too fast.

There are a few tricky elements, like managing the updating of the status, however my hope is that with some thought I can make updating status something that just happens rather than something you have to poll for.

I really wish this was a more logical api, it has elements that make it appear logical, but in practice it is very fragile and inconsistent.

Great news!

I made a little test app that just polls the status at whatever rate you request and then logs it’s successes and failures. On a usb connection I can let that run with no delay, updating the status about once every 50 ms or so.

On WiFi however it is a whole other ballgame. There anything faster than once a second causes serious issues and even a 5 second delay is unreliable. On average only 2 out of 3 messages make it thorough. The odd thing is it is super unpredictable, sometimes 10 messages make it without error and other times 10 in a row will fail.

I’m thinking of cleaning this up and asking others to run it just to see if it is my WiFi that is flakey or all xyz machines.

So I left my test running over night and managed to get over 6,000 status updates with only 15 failures.  I'll let it run the rest of the day to see if we can keep this up even longer.

I need to work out what the minimum delay is between messages to be reliable, 5 seconds is a long time to wait, I already tested out 1.5 seconds and that was not reliable.  I can live with that for status updates, but for most other interactions I would rather they trigger more immediately.  The one I'm really worried about is file upload, that requires a lot of messages get sent to the printer, if I need 5 seconds between messages it will take hours to upload a print reliably.

I have a tiny scope, I think I will toss it onto the power pins of the wifi module and see if the power is stable.  I suspect the module is either overheating (although it is quite warm now but working fine), or that it is unstable because of too much power draw.  It is also possible that it is struggling to offload a message from the wifi module to the main control board in a reasonable time, but 5 seconds should be an excessive amount of time for even the slowest of communication methods.

So I tested this with a 2 second delay between messages and got 60% failure, however moving up to 2.5 seconds drops the failure rate to only 3%.  I'm testing it now but it looks like 3 seconds is the magic value.  I will run it over night again and see what the long term success rate is.

I would love to implement the v2 protocol that the older machines use but I would need to get my hands on a machine to test against. I have a rough idea of what the protocol looks like now but it is not enough to finish the job.

If anyone in Arizona has a printer there willing to lend me, even for just a day I can probably work out how to print at least.

I just checked in code that moves the rest of the commands into the state system.  However I still need to clean up the file and print commands so they don't block.

One side effect of this is that I have temporarily removed all the delays I was using to keep commands from bunching up together.  That has no major impact on usb but probably breaks wifi.  The next step is to put in waits internally so that wifi does not talk to fast to the printer.

The member arhodiewithsoul was kind enough to send me a stripped down da Vinci 1.1 Plus, basically just the electronics and enough sensors to get the machine to boot. 

I can't quite get my head around this machine.  It is clearly a one off that was suppose to be there flagship product, before they went with the 1.0 Pro machine that is.  It sort of communicates via the v3 protocol, but it does not work well with it.  Over wifi the connection is closed after every command is sent, and on usb the connection occasionally just locks up.  I need to investigate more but that does not seem to be the case with the older v2 protocol.

Also the latest XYZWare clients don't seem to support it well.  With XYZWare 2.1.32.3 I can't get it to communicate over usb, however it seems to work on wifi just fine.  With the newer XYZMakerSuite I can't get it to recognize the printer at all, and the printer model is not even listed as supported.  I'm thinking of rolling back to a much older version of XYZWare to see how that changes things.

Anyway I was able to fix up a few bugs in my code to better support this machine, and I am now able to test out some of the v2 commands so hopefully I can at least add in limited support for that protocol.  I still have a lot of pocking around to do so hopefully I will have some exiting news soon.

Thanks again to arhodiewithsoul for the generous offer of the hardware, this is a big help.

PM'd

I encountered problems with USB and daVinci using two particular cables. Only with the printer and no other device? I had a similar problem with some microUSB cables and my R3 Uno - apparently they were 'charge only' and not 'data' cables, but I don't see how that relates to the USB 'B' type cables... ?

As long as I have owned the printer, every so often it fails to receive the .3w file for printing and throws up an error in the software.

Have tried installing XYZMakerSuite and XYZware Pro but the printer model is not supported.

So while investigating how to read the camera on the 1.1 plus I stumbled onto a 4th communications protocol.  This is basically a JSON object that is serialized then pushed out to the machine.  Here is the sequence to retrieve a JFIF image from the printer.  JFIF is a modified jpeg file.

Anyway this appears to be a complete protocol, with the ability to query for machine state and everything.  I will try to document it.

//-----------
// Image capture

=> printer

{"command":3}

<=

{"result":0,"command":3,"message":"START_SEND","length":136811}

=> printer

{"ack":"START_RECEIVE"}

<=

[JFIF blob]{"result":0,"command":3,"message":"SEND_FINISH","length":136811}