Holding single axis

Hi, Im working on quite atypical machine. Its bender with 3 axis but bending is obtained by pushing tube (in X Axis) via rollers which are driving it to next rollers which can move in Y Axis (perpendicular to X) So bigger y axis position the tighter bending radius we get. So far everything works like a charm but i've got problem with A axis caused by X axis:

1. X axis encoder is counting position from rubbered wheel dragged on the moved material (tube, profile etc).
2. When I want to rotate tube (a axis) i need to loose driving rollers to let the tube rotate and enable brake on A axis cart (to avoid loosing position in X axis) (cart with Aaxis can move in X axis)
3. When I loose driving rollers, encoder in X axis sometimes triggering and motion controller tries to come back to position but driving rollers are loose so they are rotating but the material and encoder not. So I have X axis error immediately.

I think about three options:
1. Disable encoder counting when rollers are loos (i won't lose overall position thanks to brake on Aaxis cart) - i don't know how:)

2. Set pid deadband in X axis to 5mm when rollers are loose and get it back to original setting after closing the rollers.

3. Disable X axis when roller are loose - i don't know how:)

I was trying to change deadband via m code but nothing happens. When I execute hal command deadband changes but via Mcode nothing happens. Why?

M101 code: M102 code:
Other Mcodes works

Maybe there is any other solution?
Regards

I think that I would do this with a custom HAL component that holds the X encoder position when triggered.
But I think it can probably be done with standard components, just not as neatly.

You need to accumulate an offset in a HAL signal and then subtract that from the encoder position number before passing it to motion.

(Note that subtraction in HAL is done by using the sum2 component with a negative gain on one input)

The built-in sample-hold component in HAL only works with integers, and this will need to work with floating point numbers. The workaround is to use the mux2 component looped back to itself.

I think that this structure of 2 x mux2 and 2 x sum2 will do what is needed, but my only "testing" has been looking at the picture and imagining the numbers on the pins  

Thanks for response. That is brilliant idea but when i change mux2.0.sel =1 and mux2.1.sel=1 it seems to go in endless loop. (endless counting). Am i doing it in the right way?

I did admit that I hadn't tested it.

After some trial and error, this seems to work. It is a standalone config that you can try with "halrun -I test.hal" if you save it as test.hal. Then you can "sets encoder 100" to change encoder counts and "sets hold 1" to set the hold input.

 

Thank you for your effort mate!!
I've managed to solve the problem with setting deadband to 5mm just before unlocking rollers and 0.05mm after closing them it's just simpler for me and it works.

My next problem appeared when i was trying to do this automatically with LOCKING_INDEXER_JOINT = 2

I cant get joint.2.unlock, unlocked, etc.. pins

I can't understand this from documentation:

"

unlock_joints_mask=jointmask

The jointmask bits are: (LSB)0:joint0, 1:joint1, 2:joint2, ...

Example: loadrt motmod ... unlock_joints_mask=0x38
creates unlock pins for joints 3,4,5

"

Where I should use this? Hal? INI?

I'll end work for today, its too much for one afternoon:)
Regards Maciek

bednarzmac wrote:

Thank you for your effort mate!!
I've managed to solve the problem with setting deadband to 5mm just before unlocking rollers and 0.05mm after closing them it's just simpler for me and it works.

Ignoring the encoder might give a technically better solution. If so, the answer is above.

My next problem appeared when i was trying to do this automatically with LOCKING_INDEXER_JOINT = 2

At the moment locking indexer is only allowed with rotary joints. I don't know if that is the issue.

Example: loadrt motmod ... unlock_joints_mask=0x38
creates unlock pins for joints 3,4,5

"

Where I should use this? Hal? INI?

Probably in the HAL, but it is possible that the HAL gets that line from the INI.

It will be early on in the HAL file, wherever it is.