Good question. I know this is confusing. I haven’t figured out how to delete repositories on GitHub yet. The branches are “GroundControl” and “Firmware”. Not “GroundControlUpdate”, “MaslowCNCFirmwareUpdate”, “HoleyMaslow”, or “MaslowCalibration”.
I was able to “pin” the two that are intended to be under active development. That just means the other four are not visible on the “Overview” page. Hopefully this clarifies.
Just an observation. Adjusted the gc.ini with the results of the .py and launched the last 2 links here to FW/GC HC and could not raise Z. The sled raised instead. Reversed back to main and could raise Z with the menu. Starting regular GC a message showed up the eeprom could not be read and defaults used.
Reverting back to HC error: EEPROM read fail. Using default settings. shows up startong the monitor in the arduiono ide.
Edit: Sorry for the confusion. Came from an unsuccessful Due experiment and in the Arduino ide serial monitor i could find this
Message: Unable to find valid machine position for chain lengths 1855.06, 1858.32 Left Chain Length Greater than System Settings Chain Length LeftChainLength: 72953.81 System Chain Length: 64602
I am thinking this is all related to the fact that GC does not correctly sync parameter values with the Firmware. I am confident you never set the SystemSettings ChainLength to 64602. I am guessing this is the random number that was in that memory location when the Arduino was programmed. Because GC doesn’t respond correctly when it recognizes this difference, it is giving you a hard time.
I am guessing there is another parameter that is in the weeds, that is causing it to calculate a chain-length of 72953.81 mm.
BTW, to my knowledge, there is nothing I have done which impacts this. I believe this problem is present in the main fork of Ground Control. I don’t understand why this seems to be cropping up at this time. Have you, or others, had problems like this before?
Can only give gut feelings that there are couple of things need to be addressed. Might have to correct the numbers on the 2 bugs or not 2 bugs. We had less then 3 testers on commits, so how long this is going on becomes an investigation, rather then going one step back.
To accept like on commits becomes questionable.
i would have to go back in releases to answer, but have a pattern in place to replicate, changes of feed-rate that are most promising to achieve the ‘insane’ state of the Arduino. Had cutting plans for tomorrow, so will follow the wipe path, and if that solves everything, it’s a workaround. Not qualified for the debugging in the code.
It is not clear to me that this will fix it. I have looked, and I am not sure where/what function actually writes all parameters from GC to the Firmware. So, if you wipe the Arduino, you will remove whatever was broken, but I don’t see anywhere that all parameters are actually written to the Firmware. There is a “sync” function in GC, but I know that doesn’t work.
Unless the user goes through the calibration process. I am wondering if there are any examples of successful use of a Maslow, where the Firmware is loaded, and a calibration is not done. I am thinking a calibration is done every time.
I wish I would have read that yesterday
I guess that 1 of the broken things is, that the chain feeds out 1651mm (calibration and ‘set chain manual’) and ignoring the setting and the gc.ini. I gave up after 3 attempts to get the Maslow in a sane state with the fork, always going back to main FW/GC 1.26, getting the machine sane again and retrying.
OK. The fixes are in place, and should be functional.
Here are the updates that were made:
When GC receives value of a parameter from the Firmware that is different from what is in GC, a popup will ask you which value you would like to keep.
This one will provide you some information on when the FW parameters go out of whack. I have found that when the Arduino is first programmed, some of the parameters are very wrong. I think this is what has been causing issues for a while. When you first program the Arduino, and then open GC, you may find some parameters from the FW are not reasonable.
GC will only record the machine position once per second, which should clean up the log file quite significantly.
I have tested the changes, and they are functional on my machine.