You could use linear string potentiometers. They will certainly remember the position
I have used many Celesco-brand "Yo-Yo" encoders. They might look a bit dodgy but they work really well and are very reliable.
I normally use them where I have a hydraulically-powered slide. The objective is to convert this bang-bang actuator to a programmable axis. Switch out the hydraulic bang-bang valve for a proportional valve, hook the stainless steel "string" of the Yo-Yo to the cylinder ram and voilà...closed-loop position and velocity control 👍😎
OP stated that if power is lost, motors can be moved and positional data becomes invalid. The only preventive I have seen for this is an absolute encoder, optical or pot, which beyond cost probably doesn't matter what method is chosen. Rather than an attendant moving everything to a home position, you could code up a reset sequence to perform initial positioning and not need to have a people go out and re-home the system if the true positions are always known to the system. And as you have noted there is the possibility of the motors being moved when power is not applied. You would need to plan out the safest recovery sequence to run on restoration of power. Also, using a pot or encoder allows you to "characterize/linearize" the values between the end stops so that the value between start point and stop point can be calibrated to the value of the encoder between the points.
Hence the lengthy discussion regarding battery backup supply to the encoder and the LS7366 quadrature decoder/counter in order to keep track of the axis position.
On restoration of power to the Prop, SPI communication with the LS366 will be re-established and the Prop will read the actual position of the axis.
I’m going to test the SPI click method and see if things work smoothly simulating the main board powering up and trying to restablish communication. If so that will work. Although it looks like 4 pins are needed vs 2 but that can be managed. If it works then I’ll update the main board to invoice the LS and add a moles header for battery connection. In theory there should only be one home process ever(however long the battery/BMS survives). In which case having an attendant is no concern.
Re the yo-yo encoders. That’s not an option. Too bulky and there is already an encoder so no need for another encoder count to keep up with.
Re the yo-yo encoders. That’s not an option. Too bulky and there is already an encoder so no need for another encoder count to keep up with.
Oh heck no. That was only a BTW response to DigitalBob. I would never consider using them on a motor driven axis and certainly not much beyond a 3' range.
Very cool. Hopefully, you'll post a vid when the motors are all bolted up and moving the axes.
So one Prop/axis and linked via RS485. I am also doing this and the reason being is that I have had enough of wading through rats nests of wiring. I intend to locate my "motion modules" as close to the motors as possible and do something similar with the "I/O modules".
There are more and more servo motors showing up with integrated drives but I don't always have the budget to replace existing motors.
The Click is interesting. Someone already posted a SPIN object for the LS7366r. It works right away. They are using a SSN/CS line toggling high low before every command, I will try to see if that is really needed. I need to find someone I can pay to make a PASM version. I might miss having the encoder pins show up on the prop which is sometimes helpful on a diagnostics screen that shows all inputs. In case of problems it’s nice to look directly at the state of each encoder output. What I may do is just leave the main board alone as the encoder lines already have some termination with 100ohm and .01 cap that helps with noise on the typical 25’ unsheilded cables. Then jumper the Click board in to the same encoder inputsbonnthe Prop and run the click off the battery/5v reg. The motor has a BOB which gives 5v to the hall sensors and to the encoder. It cannot be separated at the main board side. The would mean I’d have to send the 5v to the motor from the battery over the came cat5 cable (cut traces on the main board and insert +/- battery lines instead of board 5v. Then the 3 hall sensors and the encoders will always have power. This is not a big deal probably just a few more devices to keep powered.
Edit. It seems that you must toggle SSN high low to start each counter read. This means 4 wires required. The good thing is on power up you just read the count. No other commands required.
This shows the Ls7366r and encoder powered from the battery. I metered the load from the battery to the input of the 5v switching regulator board at 34mA, which is powering the encoder and Click module. I got a Lithium motorcycle battery and charger. When the power turns on to the main board it reads the current encoder/counter value from the Click module. At 14Ah this should provide a lot of back up time. I read the lithium will last a lot longer. The problem with this charger is if when the power turns on it is always in standby and requires manually turning it in to charge mode.
I don't remember having to do that toggling stuff. I will try and dig my 7366 stuff up when I get back to base....or, I remember using the Mikro code examples which are on their site.
Your encoders don't have complementary outputs? If not, you could always consider sticking 422 drivers near the encoders and receivers at the MCU.
There are off-the-shelf ones, offered on the site that @jmg pointed to....a bit spendy for what they are.
PASM conversion: Don't we have a Spin2PASM converter? I thought I saw this mentioned here on the forum.
Have you seen the Click modules for battery management?... I'd post a link but late for an appointment.
I am wondering if it makes any sense to run the encoders off the main power 5v and if the power fails have a relay turn on and engage the power from the battery/5v reg. Let a large cap mask the temporary drop out. Or just leave the encoder direct to the battery power. It is easy to add inline complementary signals from the encoder, US digital has the modules you just plug in. But that requires an additional cat5 from the motor since all 8 wires are being used. I’ve never had an issue with unsheilded cat5 at 25’ direct to Prop inputs with a 47ohm in series at the Prop side and a 100ohm > .1uf to Gnd at the input. So if it were an issue There is an easy solution.
I have studied the device yet to see why it is required to toggle the SSN(CS) pin high low for every read. But removing it breaks it You can see the object in obex. I need to make a PASM object that automatically reads and updates a long with the count. But it also needs a method to zero the count if a real home occurs. I’d like to the the BMS You are mentioning.
Not crazy about the relay, I think I would leave the whole thing permanently on-line.
Encoders with complementary signals are relatively recent, we managed without them on much longer runs. Furthermore, the 7366 employs digital filtering, whereby a valid encoder pulse needs to persist for 3 clocks.
You can set up the 7366 to automatically set to zero, on seeing the index. You preload a register with zero or any other value such as your actual home offset and instruct the 7366 to load this value on the next index pulse.
A common homing method is to drive the axis, slowly, until an external sensor (home switch) is found and stop with a high rate of decel. Reverse direction of the axis, wait until off the home sensor and then activate the hunt for the index pulse which will then transfer your chosen home value to the actual position register.
Yes the home process hits a switch then reversed off the switch and stops. That’s where I want to reset. Are you saying you can only reset to zero by moving the motor to the first index ? Surely there’s got to be a register you can Clear on demand at any place? that’s too much work to transfer a home value on an index. I don’t have index connected and there’s no more wire in the cat5 to add it. It would require extra cables. Or just fire a pin from the prop to fake the index.
The PID watches the encoder count and will glitch on a reset from an index while moving. The PID must be idle to do an encoder count reset.
Ah, but the home offset can be stored in the eeprom...just part of the homing process. You will need to re-home if the battery dies, at which time, you rewrite the offset. 👍😎
True. But isn’t it less steps(1) just to send a clear command on home vs 1. storing and 2. reading and offset, plus the 3. offset code and extra time to do offset math instructions ?
"Read and write commands cannot be combined. For example, when the device is shifting out read data on MISO output, it ignores the MOSI input, even though the SS/input is active SS/ must be terminated and reasserted before the device will accept a new command"
"A trans- mission cycle is intitiated by a high to low transition of the SS/ input"
"A transmission cycle is terminated with the low to high transition of the SS/ input"
Clear CNTR to zero Opcode, this is already done in the obex obj
PUB CNTRClear | lIR 'Reset counter
SS(SSN,1) 'ends any communication to LS7366
SS(SSN,0) 'start communication to LS7366 Msb first
lIR:=MakeIR(rCNTR,iCLR)
ShiftOut(MOSI,SCK,lIR ,MSBFIRST,8) 'LS7366 IR WR_MDR0
SS(SSN,1) 'ends communication to LS7366
I am looking for a way to write a value to the 7366 ie store a value of 1 in a register. If the power fails on the 7366 the register loses the value and is cleared back to 0. On boot of the main Prop it will read the register and check for a 1, which means the encoder count is valid. If not valid, alert the user that a rehome is required since the 7366 has lost power.
I am looking for a way to write a value to the 7366 ie store a value of 1 in a register. If the power fails on the 7366 the register loses the value and is cleared back to 0. On boot of the main Prop it will read the register and check for a 1, which means the encoder count is valid. If not valid, alert the user that a rehome is required since the 7366 has lost power.
Yeah I was thinking the same thing but wouldn't any non-zero value mean the same thing? It doesn't power up with a random value.
For example DTR can be used to store values for later transfer to Count. Just park a value in DTR and never use DTR for anything except to read it on boot.
The MDR0 (Mode Register 0) is cleared to 0 on power up. Bits 5-4 are for index configuration.
You could set these 2 bits to = 10: configure index as the "reset CNTR" input (clears CNTR to 0) and then just never allow an index input.
Then you can read these bits on boot, if they are >0 then the 7366 has not lost power.
Well you could be sitting at zero coincidentally, so 0 count is a potential valid value.
Comments
https://anaheimautomation.com/products/ics/lsi-csi.php?tID=159&pt=t&cID=55
There was a minimum order quantity of 5.
However, not too long ago, someone on the forum posted a link to a source for single units and I believe at a lower cost.
As stated earlier, I ended up using the ready made Click module...good price and plug n play.
I have used many Celesco-brand "Yo-Yo" encoders. They might look a bit dodgy but they work really well and are very reliable.
I normally use them where I have a hydraulically-powered slide. The objective is to convert this bang-bang actuator to a programmable axis. Switch out the hydraulic bang-bang valve for a proportional valve, hook the stainless steel "string" of the Yo-Yo to the cylinder ram and voilà...closed-loop position and velocity control 👍😎
On restoration of power to the Prop, SPI communication with the LS366 will be re-established and the Prop will read the actual position of the axis.
Re the yo-yo encoders. That’s not an option. Too bulky and there is already an encoder so no need for another encoder count to keep up with.
Oh heck no. That was only a BTW response to DigitalBob. I would never consider using them on a motor driven axis and certainly not much beyond a 3' range.
So one Prop/axis and linked via RS485. I am also doing this and the reason being is that I have had enough of wading through rats nests of wiring. I intend to locate my "motion modules" as close to the motors as possible and do something similar with the "I/O modules".
There are more and more servo motors showing up with integrated drives but I don't always have the budget to replace existing motors.
Edit. It seems that you must toggle SSN high low to start each counter read. This means 4 wires required. The good thing is on power up you just read the count. No other commands required.
Your encoders don't have complementary outputs? If not, you could always consider sticking 422 drivers near the encoders and receivers at the MCU.
There are off-the-shelf ones, offered on the site that @jmg pointed to....a bit spendy for what they are.
PASM conversion: Don't we have a Spin2PASM converter? I thought I saw this mentioned here on the forum.
Have you seen the Click modules for battery management?... I'd post a link but late for an appointment.
Looking good so far, though 😎
I have studied the device yet to see why it is required to toggle the SSN(CS) pin high low for every read. But removing it breaks it You can see the object in obex. I need to make a PASM object that automatically reads and updates a long with the count. But it also needs a method to zero the count if a real home occurs. I’d like to the the BMS You are mentioning.
Encoders with complementary signals are relatively recent, we managed without them on much longer runs. Furthermore, the 7366 employs digital filtering, whereby a valid encoder pulse needs to persist for 3 clocks.
You can set up the 7366 to automatically set to zero, on seeing the index. You preload a register with zero or any other value such as your actual home offset and instruct the 7366 to load this value on the next index pulse.
A common homing method is to drive the axis, slowly, until an external sensor (home switch) is found and stop with a high rate of decel. Reverse direction of the axis, wait until off the home sensor and then activate the hunt for the index pulse which will then transfer your chosen home value to the actual position register.
Wonderful device 👍😊
The PID watches the encoder count and will glitch on a reset from an index while moving. The PID must be idle to do an encoder count reset.
You can write to the position register at any time.
After homing, the counter will have some random value.
Assign it to a variable:
"A trans- mission cycle is intitiated by a high to low transition of the SS/ input"
"A transmission cycle is terminated with the low to high transition of the SS/ input"
So I am just throwing stuff at you 👍
I am tied up debugging a machine, right now but I'll dig up my 7366 stuff when I get back to my desk.
PUB CNTRClear | lIR 'Reset counter SS(SSN,1) 'ends any communication to LS7366 SS(SSN,0) 'start communication to LS7366 Msb first lIR:=MakeIR(rCNTR,iCLR) ShiftOut(MOSI,SCK,lIR ,MSBFIRST,8) 'LS7366 IR WR_MDR0 SS(SSN,1) 'ends communication to LS7366Thanks to Henk Kiela whoever he is.Yeah I was thinking the same thing but wouldn't any non-zero value mean the same thing? It doesn't power up with a random value.
Edit: I mean the position register.
The MDR0 (Mode Register 0) is cleared to 0 on power up. Bits 5-4 are for index configuration.
You could set these 2 bits to = 10: configure index as the "reset CNTR" input (clears CNTR to 0) and then just never allow an index input.
Then you can read these bits on boot, if they are >0 then the 7366 has not lost power.
Well you could be sitting at zero coincidentally, so 0 count is a potential valid value.