Sled will not go to top of board same parts are cut different sizes

After starting GC and connecting to the Arduino, If you review the maslow settings and advanced settings (don’t worry about the PID parameters, just look the parameters you know or changed) and if everything is ok, then that is a first good check.

If homing the sled goes out of the workspace area, I would suspect chain extent count is messed up or some parameter is wrong. You could redo the 12OClock reset of the chains. But before spending a lot of time going through these handlings:

I’m at work and will fix later. I did something stupid. I created two beta gc folders deciding to do 6 hole optimization. I did not remember which gc folder I had set up. I believe I sent Arduino wrong data. I just need to figure out how to cleanup this mistake? Jim

Hi, I want to apologise for whining yesterday. I went home after work deleted extra gc file, shut down all, fired up gc, set work area, and bang. Worked like a charm.
Thx, Jr

Thx all

2 Likes

Great!

Could you tell us how flat the top and bottom sled movement are on the workspace edge?

To do so, simply position the sled in the top corners and the top center as reported by GroundControl. Then check what is the vertical distance of the router bit to the real top workspace edge.
top left : mm or inch
x = -800, top y: mm or inch
top middle : mm or inch
x = +800, top y: mm or inch
top right : mm or inch

Simpler for bottom edge:
bottom left : mm or inch
bottom middle : mm or inch
bottom right : mm or inch

That would give us an estimation of the proper tuning of chain stretch, motor distance, chain tolerance, 12 OClock, Rotation Radius, motor vertical offset above workspace, …

For the chain sag, could you report the same observation (but horizontal) for left and right workspace edges as well?
top left : mm or inch
middle left : mm or inch
bottom left : mm or inch

(I would expect the left and right to be symmetrical)

I will confirm that I have seen that too and I have not been able to figure out exactly why that happens.

1 Like

Blew out left gear. Sol till New ones come.

Sorry to read that :hushed:
Could you share some details on the cause of that failure?

I’m getting “Unable to find valid machine position” after changing motor distance from 3613.15 to 3613.77. Happened immediately. This is surprising for such a small change.

I hade already homed the sled before changing the value. The motor distance was the only thing I had changed when the error came up.

I’m confused how this is a work around. Unfortunately I’ve already started the reset chain lengths. I pressed “automatic”, which never results in the same tooth going back to 12 o clock position for me. I didn’t have time to complete the process so, out of curiosity, I pressed the “move to center” button which moved the sled all the way off the bottom of the frame. I know that isn’t the correct process.

I don’t have access to the ini file tonight.

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. :man_facepalming:

@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