06-03-2020, 05:48 AM
Hi, guys
I am currently implementing a TouchDRO installation on a Maximat V10P lathe/mill combo, which is very tight for space, so I opted for some tiny Rennishaw/RLS RLB miniature encoders for all 3 axes. I opted for 1u resolution. At this resolution, the particular encoders I chose are capable of over 400mm/S, which is way more than enough. In bench testing with the Launchpad, it became clear that the Launchpad was limited to about 40kHz pulse rate which meant that any reasonably fast movement along the long axis - greater than 40mm/S - would lead to lost pulses. A provisional installation confirmed this, and another user with 0.0001in scales confirmed the issue on his machine. (I can easily move the carriage 600mm full length in less than 3 seconds). This is almost certainly not an issue for scales of less resolution. But being a little OCD, I undertook the implementation of an interface replacement using an ESP32 DevKit, which is smaller, cheaper, has integrated Bluetooth (which incidentally works very well with the Android tablet) and of course is blindingly fast, given that the quadrature decoding and counting is done in hardware and only interrupts the CPU for about 400nS once every 32mm of movement in one direction. That part is all working well (although I have not -yet- implemented any tacho functionality since I am not using one).
But that brings me to the topic of my post.
The encoders I selected have an error output (which is easy enough to deal with) and, more importantly, an index pulse which occurs every 2mm for one pulse width. Googling the index pulse really doesn't bring up any helpful suggestions as to how to use it, but I presume that it is there to enable estimation of absolute position. I have been thinking how best to implement this in the interface (given that the Android app is what it is, and I can't (and don't want to ) mess with it). One obvious way is to define a separate mode in which each index pulse sets the count within the interface to 0.000, then adjust the integer mm count using some external reference point. So the process would be something like
1. start everything up (display starts at some random value)
2. zero all 3 axes on the app, so the app position is now 0.000 all axes
3. disconnect from the interface
4. do the index pulse reset thing in the interface, so the interface reading is x.abc on all axes of interest (where x is 0 or 1 or -1 and abc is correct) (don't need readout for this, just need to move the axis more than 2mm in either direction)
5. reconnect the app, so the app now displays x.abc
6. adjust axis to a position within 1mm of the physical reference point and then carefully so that abc = 000
7. zero the axis on the app.
8. repeat 6 and 7 for each axis of interest
9. enter normal operating mode
Bit fiddly, but it wouldn't be an every day thing, and if one is careful with step 4, the subsequent steps may be superfluous.
I haven't implemented any test software for this yet although the physical connections are all in place, and the fact that I will now need some mechanism (physical or software) to enter and exit this mode remains another question to be answered.
I would appreciate any thoughts or insight that you folks out there might have.
Romeo
I am currently implementing a TouchDRO installation on a Maximat V10P lathe/mill combo, which is very tight for space, so I opted for some tiny Rennishaw/RLS RLB miniature encoders for all 3 axes. I opted for 1u resolution. At this resolution, the particular encoders I chose are capable of over 400mm/S, which is way more than enough. In bench testing with the Launchpad, it became clear that the Launchpad was limited to about 40kHz pulse rate which meant that any reasonably fast movement along the long axis - greater than 40mm/S - would lead to lost pulses. A provisional installation confirmed this, and another user with 0.0001in scales confirmed the issue on his machine. (I can easily move the carriage 600mm full length in less than 3 seconds). This is almost certainly not an issue for scales of less resolution. But being a little OCD, I undertook the implementation of an interface replacement using an ESP32 DevKit, which is smaller, cheaper, has integrated Bluetooth (which incidentally works very well with the Android tablet) and of course is blindingly fast, given that the quadrature decoding and counting is done in hardware and only interrupts the CPU for about 400nS once every 32mm of movement in one direction. That part is all working well (although I have not -yet- implemented any tacho functionality since I am not using one).
But that brings me to the topic of my post.
The encoders I selected have an error output (which is easy enough to deal with) and, more importantly, an index pulse which occurs every 2mm for one pulse width. Googling the index pulse really doesn't bring up any helpful suggestions as to how to use it, but I presume that it is there to enable estimation of absolute position. I have been thinking how best to implement this in the interface (given that the Android app is what it is, and I can't (and don't want to ) mess with it). One obvious way is to define a separate mode in which each index pulse sets the count within the interface to 0.000, then adjust the integer mm count using some external reference point. So the process would be something like
1. start everything up (display starts at some random value)
2. zero all 3 axes on the app, so the app position is now 0.000 all axes
3. disconnect from the interface
4. do the index pulse reset thing in the interface, so the interface reading is x.abc on all axes of interest (where x is 0 or 1 or -1 and abc is correct) (don't need readout for this, just need to move the axis more than 2mm in either direction)
5. reconnect the app, so the app now displays x.abc
6. adjust axis to a position within 1mm of the physical reference point and then carefully so that abc = 000
7. zero the axis on the app.
8. repeat 6 and 7 for each axis of interest
9. enter normal operating mode
Bit fiddly, but it wouldn't be an every day thing, and if one is careful with step 4, the subsequent steps may be superfluous.
I haven't implemented any test software for this yet although the physical connections are all in place, and the fact that I will now need some mechanism (physical or software) to enter and exit this mode remains another question to be answered.
I would appreciate any thoughts or insight that you folks out there might have.
Romeo