position feedback sanity check

ok, i am not even sure how to test the code..... 

Place the .comp file in the source directory linuxcnc/src/hal/components and re-run make.

but i installed thru apt on raspbien, because i am using a raspberry, another asset laying around the corner of the labmaybe I should just hide the comp sepcfic part, and tested it as .c just to test the SPI is working first. But C IDE on raspbein, another topic to research on. .....man, i want my friday beer already.

ok, this is super weird. 
..
so i use the sensor conversion distance as fb, and send the distance cmd thru the GUI  which is axis,I have the stegen in velocity mode, and the show pin files i attached also show how i net the vel-cmd from joint-vel-cmd to stepgen-vel-cnd, however the change of stepgen-position-fb told me that when i send the cmd of Y(whatever) the stepgen will produce that position regardless of the sensor feedback. 

I thought when in velocity mode, the joint will keep traveling until the motor-pos-fb reached that number but from the data, it seems like stepgen-position-fb is what we should be controlling. and stepgen-position-fb is based purely on the scale defined with each step of the stepper.

I think i am missing something here, because it makes no sense that the system are still trying to reach stepgen-pos-fb to the target value. when i auto-gen how a PID from pcoonf wizard thing, the PID loop generate would still have to the output of the PID going into the vel-cmd and there is not way to control the step-gen-pos-fb, SO, the question is what exactly is happening? 

#

---

net y-index-enable  <=> pid.y.index-enable
net y-enable        =>  pid.y.enable
net y-pos-cmd       =>  pid.y.command
net y-pos-fb        =>  pid.y.feedback
net y-output        <=  pid.y.output

# Step Gen signals/setup

setp   hm2_5i25.0.stepgen.01.dirsetup        [JOINT_1]DIRSETUP
setp   hm2_5i25.0.stepgen.01.dirhold         [JOINT_1]DIRHOLD
setp   hm2_5i25.0.stepgen.01.steplen         [JOINT_1]STEPLEN
setp   hm2_5i25.0.stepgen.01.stepspace       [JOINT_1]STEPSPACE
setp   hm2_5i25.0.stepgen.01.position-scale  [JOINT_1]STEP_SCALE
setp   hm2_5i25.0.stepgen.01.step_type        0
setp   hm2_5i25.0.stepgen.01.control-type     1
setp   hm2_5i25.0.stepgen.01.maxaccel         [JOINT_1]STEPGEN_MAXACCEL
setp   hm2_5i25.0.stepgen.01.maxvel           [JOINT_1]STEPGEN_MAXVEL

# ---closedloop stepper signals---

net y-pos-cmd    <= joint.1.motor-pos-cmd
net y-vel-cmd    <= joint.1.vel-cmd
net y-output     <= hm2_5i25.0.stepgen.01.velocity-cmd
net y-pos-fb     <= hm2_5i25.0.stepgen.01.position-fb
net y-pos-fb     => joint.1.motor-pos-fb
net y-enable     <= joint.1.amp-enable-out
net y-enable     => hm2_5i25.0.stepgen.01.enable
#

---

and i change the pos-cmd, vel-cmd, and pos-fb as follow to use the distance sensor reading without PID to begin with, i tried PID directly, it make the system unstable and it seem like it will take a long time to tune the values, so i 

net ypos-cmd joint.1.motor-pos-cmd 
net yvel-cmd joint.1.vel-cmd => stepgen.1.velocity-cmd stepgen.6.velocity-cmd
net ypos-fb ADS1158_SPIhal_F.out => joint.1.motor-pos-fb

 

Using PID with FF1=1 and P,I,D = 0 is basically identical to your hal connections ( which are open loop) but with the advantage that you can add whatever amount of P term is required to close the loop.

guys, good news, so it works. i got to do python some justice now.

despite the potential response and delay that uerspace and what is more in python, for many sensor anything faster than 1ms is enough, and in fact, the update is perfectly, i got the based thread time increase to 200us, and the motion is tracked fine, and nothing seems bad. and the most of the time the sensor doesn't change value until after 1ms which is what i expected anyway. so, using python component and feed the value from userspace into motor-pos-fb is completely workable and viable option.

because the update rate of the system is so fast, 100us on average, from the 30s data i took. just having a simple P control of 1 is enough, why? if we recall what is being taught in control theory, if your observation of error is very fast,> 100x of the actual change from the physical system, then your simple P control will have a reduced value as the current position approach the target.

Also the drop out i experience with the original setup has nothing to do with the code nor linuxcnc, it is jus the Rpi we had in our lab is shit, I asked a friend of my to test on his Rpi, he questioned my sanity, because the feedback via SPI is perfect, and there is not drop out. So... yeah, maybe we just have to get better equipment.

this mean that anyone could just hook their axis up with any sensor and make sure it is output a float value to the motor-pos-fb, and hijack the signal from the default PID control.

the only problem is that the sensor i used does give an error and the output flicker a lot if the system is vibrating. but as far as the system and procedure is concerned. we are use any type of sensor to do the feedback.