If we had no other registers to utilise, this would be where I would consider preloading the position register with something ridiculous, like 1,000,000,000
and go with the aforementioned offsets. A preset value where zero could never occur except for loss of power.
Well DTR is used for storing a value to load into count and if you don’t intend to replace Count then it’s a nice unused storage space. I’m looking for the fastest loop and offseting will add time. So I think the DTR is easy. Just read DTR once on boot. On a fresh home, set DTR with a value. So writing the offset as you described takes the same effort as writing DTR.
Side note. If for any reason your encoder/click were to update or reset while everthing was up and running your PID error would be massive and the motor would take off full speed. You could before every move check for a valid flag in DTR which would add a one time check before a move. I’d hate to add more stuff to do inside the PASM PID loop though. So it is possible that even if you weren’t using an offset the potential still exists for an accidental runaway PID without using offsets. This is the risk of an external count vs a Prop count. So some protection may need to be added to prevent a reset 7366.
Edit. The PASM 7366 loop will shut down the system if no data is received.
Yikes, a PID loop in PASM is a breeze. Most run at 1KHz and the highest end motion controllers hit 8KHz...orders of magnitude beyond the mechanical element's bandwidth.
In fact, I have been using a "servo rate divisor" for the D-term-only which factors the error from X previous samples to provide better velocity damping.
Edit: You should also have following-error traps to avoid runaway.
There is a register called STR (status register). On power up bit 2 is set high to indicate power on. After power on, you can Clear the STR to zero, then watch that byte for a 1 to indicate it has power cycled. It was designed just for the purpose of indicating a power cycle.
PLS: Power loss indicator latch; set upon power up
I made some boards for the Click that includes a 5v regulator. This board gets inserted via cat5 between the main board and the motor. The hall sensors and home switch pass through the board. The power for the hall sensors and encoder now come from the battery supply. This is an easy upgrade for systems I want to add the battery back up to. The Click worked out nicely. The Spin code is close so I’ll post it soon. Since there are a number statu me checks going on along with reading count I am converting the Spin SPI driver to PASM with fast spin So the main Spin PID loop will always have a more resent position vs a spin Spin SPI loop which has to read count, power on status and I’m also scanning other status flags too like quadrature mode etc.
4 day turn on PCB! I already had a stencil for a 5v reg board so I just added the Click onto the same design. I’m getting used to the 7366. Lots of extra work to beat down the caveats but there are some advantages. For example I have a 75:1 gear motor bldc with encoder and a clutch on the other side of the clutch. The output must stay synced with the motor. So I am connecting two encoders to the same SPI bus with extra CS line to the second click. Then perodically compare the motor count to the output count x 75. If different then offset the motor count with the difference or other options. By the way the 5v reg + Click + encoder is 35mA. The 14AH batter is lasting 3 days easily but I haven’t bothered to see where it really stops working.
Another thing I’m doing is since the SPI loop is growing I have a simple way to convert it to PASM with fastspin which makes up for all the extra code.
Yay... Dual-loop-feedback...it's what I have always done/preached. In my case, it's not because of a clutch, it's because I am interested in the position of the load, not the motor shaft-angle. Motor-mounted feedback for loop stability and load-feedback for precise positioning. On linear axes, I use a Sony Digiruler (linear scale) with 0.01mm resolution.
Progress on the dual encoder. I have experimented with a fastspin convert of the SPI 7366 management loop. There is a bit going on in the loop, not just simply reading the count. The fastspin puts the Cog at its max memory and there is stuff still to add for the second encoder. That puts fastspin conversion over the limit and I don’t know PASM enough to write it from scratch. I’m finding that spin works fine for the loop with reading one encoder. Not sure If there will be an effect after reading the second. But since the second encoder is to verify sync then I may just read the second every 100 iterations as it is only used to trigger an error. What I don’t want to happen is that the pulse motion profile generator falls behind a count on the encoder and PID tells the motor to reverse. I like the PID loop to always have a real time count and it will trail just behind the profile pulses. A graceful decel avoids reversing correct.
What I don’t want to happen is that the pulse motion profile generator falls behind a count on the encoder and PID tells the motor to reverse. I like the PID loop to always have a real time count and it will trail just behind the profile pulses. A graceful decel avoids reversing correct.
I am getting almost 4 days on the 14AH lithium.
Who is more clutterier than my bench?
Hmmm, the motion profile generator is the command that the motor/encoder attempts to follow. Typically the motor lags which results in the following-error needed for the PID to generate an output. If the motor was perceived to be ahead of the command, all the PID should do is pull it back.
How many 7366s are powered for the 4 days of battery life?
I am testing 1 right now connected to the 5v reg including 1 encoder Today it will become 2 7366 and 2 encoders. Even if it stays up 2 days that’s fine.
The clutch power pcb has an ACS712 current sense ic. It only outputs a small change for 1 amp so I ran it into an opp for gain and ran it to a comparator and with a trim pot set a threshold for a reliable output of anything over 50% duty is driving the clutch. Then the main board has a diagnostic feature to know the clutch is actually powered. The two encoders will compare to detect sync.
Interesting gadget. I’m going to mount a temp IC behind the battery and above 85F will disconnect the charger and alert the user. I found a CTEK US smart charger. It is designed to stay plugged in if needed. Just plug it in and it goes to work.
Comments
and go with the aforementioned offsets. A preset value where zero could never occur except for loss of power.
Side note. If for any reason your encoder/click were to update or reset while everthing was up and running your PID error would be massive and the motor would take off full speed. You could before every move check for a valid flag in DTR which would add a one time check before a move. I’d hate to add more stuff to do inside the PASM PID loop though. So it is possible that even if you weren’t using an offset the potential still exists for an accidental runaway PID without using offsets. This is the risk of an external count vs a Prop count. So some protection may need to be added to prevent a reset 7366.
Edit. The PASM 7366 loop will shut down the system if no data is received.
In fact, I have been using a "servo rate divisor" for the D-term-only which factors the error from X previous samples to provide better velocity damping.
Edit: You should also have following-error traps to avoid runaway.
PLS: Power loss indicator latch; set upon power up
So it seems that you have used the device in a way that it was intended to be used. Makes sense.
Another thing I’m doing is since the SPI loop is growing I have a simple way to convert it to PASM with fastspin which makes up for all the extra code.
Click + Encoder = 35mA....can't complain at that!
Looking forward to future updates 👍
I am getting almost 4 days on the 14AH lithium.
Who is more clutterier than my bench?
Hmmm, the motion profile generator is the command that the motor/encoder attempts to follow. Typically the motor lags which results in the following-error needed for the PID to generate an output. If the motor was perceived to be ahead of the command, all the PID should do is pull it back.
How many 7366s are powered for the 4 days of battery life?
The clutch power pcb has an ACS712 current sense ic. It only outputs a small change for 1 amp so I ran it into an opp for gain and ran it to a comparator and with a trim pot set a threshold for a reliable output of anything over 50% duty is driving the clutch. Then the main board has a diagnostic feature to know the clutch is actually powered. The two encoders will compare to detect sync.
https://www.odroid.co.uk/odroid-ups-c1
Bit spendy for a hobby project but I could easily justify one/axis on a paid project.
Edit: I should point out that it is shown sitting on top of an actual Odroid module.