INIFILE: ERR_CONVERSION for gantry configuration (2.8.0-pre1-4740-g60416609a)

You seem to have HOME_SEQUENCE = 1 for all axis. I believe they should start at 0 usually for the Z so that it homes first, then the next say Y (for a gantry type with two motors) this needs to be a minus ie HOME_SEQUENCE = -1 for both joints and the last would be X with a 2.

I think that you cannot miss a number out and start with 1

This is assuming you are using 2.8

dgarrett wrote: Errors like:

Code:

INIFILE: ERR_CONVERSION, section=JOINT_0, tag=HOME, num=1, lineNo=105

are due to the following bogus ini file entries:

Code:

... [JOINT_0] HOME = Xmin ... [JOINT_1] HOME = YLeftMax ... [JOINT_2] HOME = YRightMax ... [JOINT_3] HOME = ZMax ...

The values for HOME= must be numeric.
If these lines were created by a configuration tool,
it is broken.

Dewey, the OP put those values in and my tool failed to verify that the number was actually a valid float.

JT

JetForMe wrote: One question: I'm looking at the gantry docs. Do I need to include that in my config? Things seem to be working without it, but it seems like it offers some things I want.

You don't need gantry at all with version 2.8. Its essentially obsolete. Just follow the correct V 2.8 documents to set up homing.

Please confirm the version in use. Earlier you said you were using V2.8.

You still don't have HOME_SEQUENCE = -1 for joints 1 and 2 so homing will not square your gantry.

I noticed a couple of things in the ini file which are probably from John's configurator

Initially, I thought this should have been XYZ but I see it is now valid to be formatted like this in the docs:
I'm not seeing AXIS = n is valid in the joint section but it won't break anything. It probably should be commented out.

Just to be clear as the message seems to get lost somewhere somehow:
You must have. -1. For the axis with two joints for home sequence in the INI file.
Now change that before you bend something beyond repair.
Oh and press home all, it does work properly , after you fix the above.

Just to be even more clear from the 2.8 documents

Negative HOME_SEQUENCE values indicate that joints in the sequence should synchronize the final move to [JOINT_n]HOME by waiting until all joints in the sequence are ready. If any joint has a negative HOME_SEQUENCE value, then all joints with the same absolute value (positive or negative) of the HOME_SEQUENCE item value will synchronize the final move.

linuxcnc.org/docs/devel/html/config/ini-....html#_home_sequence

JT

Ah, I see why negative is important. I had gotten it in my head that "-1" meant somehow excluding that joint/axis from homing altogether.

I'd argue that it would be a lot clearer to have a separate configuration parameter for specifying that two or more joints should be synchronized, and how they should be synchronized. This would allow joint-mode jogging, for example, if I could tell linuxcnc that two joints must always be synchronized.

I'm also worried that specifying -1 won't be enough, as it only synchronizes the final move, but (evidently) not the search for home or the latch move.

Lastly, to tommylight, I've been reluctant to "home all" precisely because I'm not sure everything is configured right. Having said that, it's working pretty well now, and I've been using Home All successfully even without the proper sequence configuration. I'll be making that change next.

I do understand your reluctance as I was in that same position some time ago, with a big industrial machine with a gantry weighing in at over 400kg, I had my finger twitching over the e-stop for nearly an hour till I convinced myself that it is working properly and loosen up.
Glad you got it working.
Regards,
Tom.

Its perfectly fine. I've been using it for about 3 -4 years. What happens is the first side that hits the home sensor stops and waits for the other to catch up. Then they both go through the sequence together. Its quite amazing to watch if you rack the gantry, particularly at slow homing velocities. Final squaring can be done via the offsets in the .ini file

JetForMe wrote: Ah, I see why negative is important. I had gotten it in my head that "-1" meant somehow excluding that joint/axis from homing altogether.

I'm also worried that specifying -1 won't be enough, as it only synchronizes the final move, but (evidently) not the search for home or the latch move.

To be clear the negative sign makes sure that when homing both gantry motors are driven together until one of them hits its own home switch then that motor stops and the other caries on until that hits its own home switch.

Then the magic happens and both motors go to their respective home offsets (as setup in the in file) So one could offset to say 2mm and the other to 2.3mm (or what ever it is the gantry is out of square by)

Clive, nicely explained. Thank you.