Yeah it seems to be just like krkeegan said that every time I quit and restart ground control or restart the whole computer it loses the chain calibration lengths. The GC screen still shows the red crosshairs and white crosshairs aligned at X0, Y0 which is where I left it. I haven’t experimented with moving it to a different location and closing and restarting there. I can give that a try just to see.
It seems to give those errors but sometimes it’s like it will allow me to just say ok or continue and then it is still working. Other times it won’t let me do anything it just keeps popping up the alert window until I do the chain calibration.
I have consciously been using the “action tab, quit ground control” sequence to exit the program and it still loses the chain length number every time so far. I still need to learn how to collect and post the logs so that I can share that with everyone.
@krkeegan, it looks like you have ‘Triangular’ kinematics is chosen in Advanced settings. I wonder if that has a bearing on the issue? Have you done a chain cal in that mode? (does it even work in that mode?)
In the same folder as ‘main.py’ there is a file ‘log.txt’. Trash it to clean out old info, as it is appended with each run. If you get rid of it, it will be re-created on the next run.
Triangular kinematics mode triggers the issue that @krkeegan is seeing. By selecting the Triangular kinematics, the alert comes up immediately. By selecting Quadrilateral kinematics, the issue is cleared again.
There isn’t a clear procedure for setting up in triangular mode yet, it will become important as more people explore this option.
The usual forum upload method is to use zip files (they work on Linux, no need for tar.gz or whatever) rather than chasing the ever changing extension chimera. Used it for many years on many forums, plus it helps save a bit of server disk space.
Also mention the OS and maybe version you’re using. WinHose is different from LinusOS, FanBoisOS, OS/2, Plan9, etc and we won’t remember what you said a couple days ago in another post
No, both issues happen no matter what type of kinematics I have selected. Plus if I have a file opened and I don’t restart my computer, then I can open and closed GC with triangular kinematics selected without issue.
Ubuntu 16.04
Yes but only for the steps that are relevant motor spacing motor height.
I copied the settings from the log file you posted into my setup, and found that changing the ‘Triange/Quad’ switch made the re-cal dialog come up if Triangular was selected and not if Quad was selected. I couldn’t get away from the dialog if Triangular was selected.
I had missed this in the discussion above, but I can confirm that if there is no file open, this causes the re-cal dialog to come up as well. Opening a gcode file (if the settings are otherwise correct) prevents the dialog from coming up.
To sum up:
there are two issues here, both cause the chain re-cal warning to pop up:
‘Triangular’ kinematics selected in Settings/Advanced (not sure of a workaround)
no gcode file open (work-around is to open a file)
GC issues #54 and #55 opened to capture these two.
If you select triangular kinematics, but have the traditional sled, then you can
easily get into a situation where the chains are not long enough to meet, and it
can’t calculate where you are.
There should be a big warning about that mode, possibly with some pictures of
what the sleds look like that you need to have to use it.
I will look into this. But keep in mind that if your encoder positions are in a place where my triangular settings could not reach then you would get this error. I think if you put your sled in the low center of your worksurface you will have the greatest likelihood of these settings working.
My chains were in the calibrated position and all the other settings were copied from the log you sent. I thought you sent the log because you were getting the re-Calibrate dialog. I commented about the Triangular Kinematics because it caused the dialog when I made the selection, and was repeatable.
Do you think the issue in your case was the lack of an open gcode file? That would seem to do it. Have you found that you’re good to go with a gcode file open? That’s the desired situation We’ll have to correct the issue, but identifying it and finding a workaround are a start.
I’m not clear on the restart version of the issue. Do you mean that the re-cal dialog comes up every time you run GC after restarting your computer, whether there is a file loaded or not?
[Edit] On my system it appears to matter whether the gcode file is in inches (G20) or mm (G21). If inches, the workaround is valid. If the file is in mm, the dialog appears with chain lengths 0.00 when GC is started.
Spent some time working on this tonight. I have been focusing on the complete loss of position that happens on reboot.
I added in some logging and I can see the eeprom data being written and the same data being read back properly after reopening GC. But for whatever reason, after I restart my computer, the reads come back as 0.
I tried reflashing the arduino after a reboot to see if some how “waking up the arduino” would help. It didn’t.
I used the B07 command to wipe the eeprom, it didn’t help.
My only other thoughts:
I am going to try adding some delay on startup, to see if maybe the arduino needs time before reading the eeprom?
Use some sort of eeprom.clear sketch to wipe the entire eeprom.
Add a BXX gcode to dump the entire eeprom contents
As for the no openfile issue, I am pretty sure the warning that happens in this case is generated by GC not from the arduino, which is why we are able to recover from it.
Honestly I used both, but inches more commonly. Neither seemed to make a difference.
The reading zeros from the EEPROM is my main focus. Why does it return valid numbers until I restart my computer? Why does restarting my computer have any effect on this? All very strange.
@bar why the custom read/write EEPROM functions rather than just using the GET/PUT functions in arduino?
If I remember right the custom functions are there to let us store floating point numbers in the EEPROM which I thought the built in functions couldn’t do but if I’m wrong I fully support switching to the built in functions
We’ll have to correct the issue, but identifying it and finding a workaround are a start.