That’s a good idea - will you open an issue for that?
1 Like
3D printer controllers have problems with eeprom and firmware corruption if you drop power while printing. The voltage spike from the collapsing stepper coil fields is usually blamed. Wonder if it’s related?
SUCCESS!!
The clues were the zaxis data being valid. And the “flag” we set for valid eeprom data still being there.
Apparently when I reboot my machine, something causes a connection to the arduino (I am no expert I don’t know what is required for that). The arduino runs through the setup phase, and then enters the main loop at least once.
The main loop calls holdposition() which calls detach() on each axis. Detach writes the positions to the eeprom. Of course since we have not received any machine settings, these values are 0.0.
I solved it by not allowing a position of 0.0 to be written to the eeprom, but this seems wrong. The zaxis is capable of 0.0, the other two maybe not.
I wonder if the best answer is to shortcut the main loop. If we have not received valid machine data, then the main loop shouldn’t be trying to command the axis.
Other ideas?
3 Likes
Sure. I can write the fix too, there are very few lines to change.
1 Like
That will be great. 
1 Like
So, a flag initialized to false and set true when both B03 and B12 have been received? That seems reasonable.
When GC starts up, it restarts the Mega, which will set the flag to false and wait for the B03 & B12 again. Are there use cases where that would cause issues? I canb’t thing of any.
1 Like
I am still poking around in here, but this all seems very fragile, I am a bit surprised we haven’t had more issues with this.
At the same time, I can’t figure out exactly why the error I am seeing occurs, in order to get the the point of writing to the eeprom we must first attach the motor. I think in order for that to happen, I have to be unlucky enough for whatever this is in my computer to send something like G00 G01, G02, or G03.
Also, in talking to a friend, he thinks that networkmanager in ubuntu is the culprit because it tries talking to any serial device.
1 Like
It is a really fragile sustem right now. It’s been changed a lot and very quickly over the last couple months and its probably time for a pretty much ground up rewrite now that we have some sense of what we want.
If you have thoughts on what the connections order of operations should be, it would be more than welcome or if you want to just re-write it so it works for you that is always more than welcome too
2 Likes
Mine is rock steady and pumping out cuts and projects with infrequent minor issues. I have the standard frame and equipment shipped in the kit. I find it solid!
4 Likes
Out of curiosity, which operating system are you using?
Windows 8 on an older HP dv5000 or something like that.
1 Like
Alright, I have pushed changes to Firmware and Groundcontrol. Anyone who is having issues with the machine losing its calibration, you may want to fetch these and see of they help:
There were various oddities that caused the issues I could see. The issue where a lack of an open gcode file would cause a recoverable loss of position was caused by the arduino never receving the first command sent to it. If a file is open, that first command could be G20 if it was inches, but the error would still appear if the file was in metric because G21 was not sent.
I don’t know why the arduino doesn’t see the first command, and my solution may be a bit of a hack so I opened Issue#404.
The wipe of the EEPROM data was fixed by creating a whitelist of safe commands that can be run without the machine settings, all other commands will fail unless the B12 and B03 settings have been received. This seems to work well, and handles connection timeouts and usb disconnects with ease. But I would appreciate it if others could look for bugs just in case.
I also switched us over to get/pull/update EEPROM commands which is both easier and should extend the life of the EEPROM.
1 Like
I’d bet that something else is talking to the serial port as soon as it gets
connected, and the remainder of that command corrupts the first command you try
to send.
can you either setup debugging and look in the logs or hack together a little
debugging that will have it save everything it’s sent and repeat it back when it
gets a specific command?
I tried
adding a delay before sending the first command up to ten times longer than what sending a command takes
I also added in logging on the Arduino and never see any evidence of the first command.
I wouldn’t expect a delay to help, but if something (like network mangler)
connected to the serial port and sent an AT command to try and detect a modem,
it would then look like that was prepended to the first thing sent by ground
control (and anything sent out at the time it’s received could have been
intercepted by whatever software is interfering with us)
try setting your system logging to log to debug level and see what shows up in
the logs when the device is plugged in.
I will try, but keep in mind, the eeprom error only happened in reboot, but this error happens every time.
So I tried a completely separate machine, a Windows 7 machine, and the arduino still doesn’t report ever seeing the first command sent. So this happens on both Windows 7 and Ubuntu 16.04.
I suspect it is something in our firmware, but I still don’t know what it is.
1 Like
You’ve chased this bunny very thoroughly, a commendable effort.
If you’re looking for a fresh approach, maybe try using Wireshark to capture the USB traffic for that serial port.
Perhaps we should add some code in Setup() right after opening the serial port, to throw away all characters until a space followed by a new line is received (serialPortThread.py line 93.)
While we’re in that part of serialPortThread.py, there is a bit of jiggery-pokery with the serial settings in lines 83-88 that might be part of the issue. Do these cause the Mega to reset? What is their real purpose/effect?
1 Like