Such a small change when done while the sled is near the center of the workspace is not supposed to create that error.
To be sure where is the problem, it would be necessary to compare the parameters list (ini file) before and after the change.
Also, what firmware version and what Control version do you use?
Iâll be sure and pay attention to this going forward.
@Joshua âs holey fw and GC.
A still unconfirmed claim from me is that some setting changes can leave the arduino in a strange mood, that only shutting down GC and unplugging the arduino can heal. Until I have confirmed or busted this myth, I change setting in the .ini with closed GC.
1 Like
Thanks @Gero. I disconnected power but I think I forgot to close and reopen GC. 
@c0depr1sm @Joshua not knowing how reads and writes to the ini file actually works now⌠Would it be helpful to [automate the INI file status] (configparser â Configuration file parser â Python 3.9.2 documentation)?
As of now, I studied the firmware quite extensively, but I am not familiar with the inner workings of GroundControl.
@c0depr1sm, what firmware version were you using then, and now (just curious)? I continue to get this error, and others are still reporting it. There is something wrong in the fw or GC if we are getting this error after homing the sled and only making small parameter changes. Iâve only ever used v1.25 then Joshuaâs holey fw update (not the GUI update version).
Other than âMaslowâ and âadvancedâ settings, what else is in the ini that would be relevant to check? If the only change is a very small parameter change which results in this position error, seems like that part of the code needs evaluated. Itâs as if something else needs to be recalculated and it isnât being done correctly or at all. Maybe the position error should be ignored if the machine isnât running?
In my mind, this is related to how and when GC syncs with the Firmware. This âmoodâ is just the Firmware not being up-to-date with GC.
2 Likes
Basically, everytime I got that error, I had exceeded the conditions I explained as the âwhat , why and howâ above. After analysing the Firmware architecture, I created a summary of the calculation loop.
Step 0 is the one that estimates x,y position from chain length and yields the error when unable to resolve (x,y) from the maslow parameters and chains length.
More generally, I see three possible causes:
- parameters are set in the firmware as requested by the user by Groundcontrol, but are wrong.
- parameters are not set properly in the firmware due to a bug along the path
- the Forward Kinematics calculation fails in some cases.
To debug this, it is very valuable to
- know the exact firmware and GroundControl version in use when the bug is observed,
- observe what was actually set into the firmware
- observe what was actually set in GroundControl.
To collect the GroundControl settings data, one gets and reads the groundcontrol.ini file.
To collect the Firmware settings data, one sends the $$ command (with the correspondingly configured macro button) to the firmware and look the response printed in the GroundControl shell output. I can easily see the shell output because I launch GroundControl in a shell with the command âpython ./main.pyâ. I donât know how to get the same with the windows version.
Encoder counts are not output by the $$ command. But the encoder counts are not normally affected by a parameter change like the motor distance.
After a parameter change (and assuming the chosen parameter value is right ), if the sled position cannot be solved or center position is visibly not where it should, then here is what I would do:
- donât do any calibration task yet. Keep calibration as is.
- close GC, turn off the arduino (disconnect usb and turn off motor shield power source.
- restart the arduino and reconnect with GroundControl to reload and recompute forward kinematics.
Do you still get the âunable to resolveâ error?
- If no, that could point to a bug in the firmware not using the new value properly upon change, but doing fine upon reset.
- If yes, check again $$ output and GroundControl settings for unexpected values among the parameters. There might be some wrongly set value, pointing to a bug in the communication path used by GC and the firmware to set a parameter.
1 Like
Im using the latest gc and latest firm from the ground control master update. If i use the calibration and holey in the step by step calibration pushing data to machine blows up gc, it crashes. I am force to do the calibration, and then enter data manually. I am not able to enter the between motor numb er tho, blows it upl
tell me what u would like me to do to get u good data. something is wrong,. and steer me to latest firmware and gc. maybe there has been update. JR
Is this using the GUI?
I am going to go through the Holey Calibration process on my machine. However, I will not be able to get to it for a while, because I have family commitments this weekend. If this is a bug in the software, I should be able to reproduce it on my machine.
Iâm a firm believer in using the code I write.
hi,
i re did holey optimization on top of one done before. i triple checked all measurements. I added offset, lft, rt correction ok. shut gc down between each add. then added distance between and got set chain error. Set chains and I knew this would happen, on move to center sled went extreme top left, I had to stop it as itwas going over top of board at left.
i changed destance between back and miracle bullseye went to top left position in gc. I did not have to set chains again.
I use default in between measurement, 2978.4 . holey optimized is 2946. JR