Holey Triangular Calibration

which branch?

I cloned master from https://github.com/schmittjoshc/GroundControlUpdate. and when I do a git pull it says I’m up to date, and git log shows nothing since April 7

I do see the commit when I go to the github website, so I’m digging to see what is wrong


it looks like the weight change was added to /groundcontrol/ not /groundcontrolupdate/

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”.

Here are the links:

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.

3 Likes

thanks, I apparently cloned based on an earlier set of instructions, fixing this
now.

David Lang

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.

Are you saying the sled went up along the y-axis?

yes, instead of z, the sled moved up on Y axis.

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

Wiping all and checking again…

1 Like

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?

2 Likes

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.

2 Likes

So, this issue showed up between 1.25 and 1.26?

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.

2 Likes

see the topic asking what should happen when the arduino and .ini files differ,
with the current version of GC, wipe the arudino and start again.

David Lang

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.

If wiping the eeprom doesn’t work, then there’s no way for a brand new arduino
to get the parameters loaded.

David Lang

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.

FYI, I committed some changes to my GC fork. There may be some things which are temporarily broken.

the prompt for sled weight should ask for the weight in pounds or Kg, not
in Newtons, let the program do the conversion. :slight_smile:

David Lang

I wish I would have read that yesterday :sweat_smile:
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.

2 Likes

What is this and how should i react to it? ( admitting this is on the AMega in the office and not in the workshop)

Edit: a ‘back’ bottom could find it’s way into one of the next releases just in case i repent the answer of the previous question :slight_smile:

Edit2: ‘set chain manual’ does the length as expected.

2 Likes