Linear scale correction: homing to index

More
13 May 2014 23:40 #46891 by PCW

The clear on index is one thing, but I hate the bidirectional logic used


I agree 100%. Index enable causes lots of trouble. A 2 wire handshake with in and out signals would
be much better since you could use standard hal components to do additional index processing
(such as index masking with general HAL signals)

Please Log in or Create an account to join the conversation.

More
14 May 2014 00:04 #46895 by andypugh

How does HAL determine in what order to execute logic? Start with the component at the source of a signal, end at the destination?.


The functions run strictly in the sequence in which they are addf-ed.

You can over-ride this with a rarely-mentioned third argument to an "addf" command. As far as I know it is only documented here:
www.linuxcnc.org/docs/html/man/man3/hal_..._to_thread.3hal.html

Please Log in or Create an account to join the conversation.

More
15 May 2014 02:26 #46938 by DaBit

The functions run strictly in the sequence in which they are addf-ed.


Well, that's a tricky one. If you have three levels of logic and you addf them in the wrong order you suddenly have a 3-cycle latency. That could cause some surprises...

Anyway, I did a quick test:
- I removed all the offset stuff I still had in the HAL file and which is not necessary anymore since I hardwired the scale encoder index to both 7i77 encoder inputs. No difference regarding following errors
- I added the index-enable pins of the PID controllers to the xindex-enable net. No difference.

- Tried to catch the f-error using HALscope. I managed to catch it. It turns out that the f-error happens only during the first homing cycle after LinuxCNC started and when there is enough distance between the startup position and homeswitch/indexpulse. And not always, which is the weird part.



The large ferror happens for only one servo period. Could it be that the hm2 encoder position is not updated every servo cycle or is just a cycle too late depending on some internal counter when LinuxCNC starts?

- Next, I added a mux2 to mux the motor-pos-fb between motor-pos-cmd and the scale encoder depending on the index-enable. So only during the distance between home switch and index pulse I lie about the actual position.

- I had to add a single cycle of extra delay before switching back to the scale position as motor-pos-fb

This seems to work :laugh:


The piece of HAL code that does the trick:
# standard components
loadrt debounce cfg=1
..
..
# index homing, position feedback and ferror suppression
net xindex_enable hm2_[HOSTMOT2](BOARD).0.encoder.03.index-enable <=> hm2_[HOSTMOT2](BOARD).0.encoder.00.index-enable <=> axis.0.index-enable <=> xservo_pid.index-enable <=> xscale_pid.index-enable => debounce.0.0.in
net x-debounced-indexenable <= debounce.0.0.out => xposfb_mux2.sel
net xscalepos <= hm2_[HOSTMOT2](BOARD).0.encoder.03.position => xscale_pid.feedback => xposfb_mux2.in0
net xpos-fb <= xposfb_mux2.out => axis.0.motor-pos-fb
net xpos-cmd axis.0.motor-pos-cmd => xscale_pid.command => xposfb_mux2.in1
..
..

Please Log in or Create an account to join the conversation.

More
15 May 2014 02:48 #46939 by PCW
Can you try without error-previous-target set (with the basic non patched config and scale index going to both encoders)

There were index thump problems re-introduced when this was added
and I thought they were fixed...

If this does not work, there is a bug that needs to be addressed

Please Log in or Create an account to join the conversation.

More
15 May 2014 03:30 #46940 by DaBit
I was happy too early...

I will try without error-previous-target set, but the problem is not in the PIDs. Something weird is happening:



encoder03 is the scale which is muxed with axis.0.motor-pos-cmd to axis.0.motor-pos-fb based on debounce.0.0.out

On the falling edge of the debounce output, when the 'switch' to motor-pos-fb is flipped from motor-pos-cmd to encoder.03.position the motor-pos-cmd changes and I get a single cycle large ferror. No matter how long I delay the index-enable to mux signal.

Please Log in or Create an account to join the conversation.

More
15 May 2014 03:34 #46941 by DaBit
I tried it: not setting error-previous-target makes no difference, either with or without debounce....

Please Log in or Create an account to join the conversation.

More
15 May 2014 03:54 #46943 by PCW
what linuxcnc version are you using?

Please Log in or Create an account to join the conversation.

More
15 May 2014 04:01 #46944 by DaBit
2.6.0~pre from git://git.linuxcnc.org/git/linuxcnc.git, rellenbergs circular-blend-arc-rc3 branch.

Please Log in or Create an account to join the conversation.

More
15 May 2014 04:15 #46945 by PCW
hmm there may possibly be bugs in the PID comp from there...
might be worth trying master

I suspect you will have to simplify what you have to trace down the bug though.

Please Log in or Create an account to join the conversation.

More
15 May 2014 04:34 #46946 by DaBit
I can try vanilla master, 2.6.0-pre1 or 2.5.4, whatever you think would be best. Not today though. But I think the problem is not in the PID's. They don't misbehave.

To my untrained eye the problem seems to be a 1-cycle-latency issue somewhere in the motion controller. axis.0.motor-pos-cmd keeps it's old value after the index-enable falling edge until axis.0.motor-pos-fb actually changes to the new value. Then there is a one-cycle period where f-error is the difference between the old and new positions.

I would expect that the motion controller latches the new position on the falling edge of index-enable, but somehow index-enable only arms the latching process and it is completed when motor-pos-fb makes a step change or something like that?

Please Log in or Create an account to join the conversation.

Time to create page: 0.182 seconds
Powered by Kunena Forum