an absolute position encoder, with a BiSS-C interface.
For safety reasons, the project requires an absolute position reading. Absolutely absolute
There shall be no homing switch, no hardstop homing, no overtravel switches. All must rely on the absolute position sensor reading.
I tested with Granity at first, while a control software (in c, calling the API) is being written.
So far so good but whenever I power the IONI on, the absolute sensor reading is reported to be ZERO (whatever its true position might be), which I rather call a relative reading . The sensor seems not guilty: whenever I unplug and replug it, it reports the same reading. Only the IONI seems to subtract the power-on position from the actual reading.
Did I overlook some option to turn the position reading to absolute ?
A relative reading would be a no-go : we need an absolute position control. Absolutely absolute
connect to granity and show all the tabs with photos, but what you are looking for is most likely position feedback device in machine tab. if your settings are correct maybe check your wiring
The sensor is supposedly absolute, and power-cycling the sensor does not change the position reading. The (optical) sensor is from Renishawās Absolute series at the moment.
I havenāt tried power-cycling the IONI but not the sensor; it takes some wiring changes but I shall try it.
Here is an extract of the code to read the position. It returns the same data as Granity does, AFAIK.
printf("Monitoring actual position...\n");
while (elapsedTime < TIMEOUT_MS) {
// Read the actual position
result = smRead1Parameter(bus, DRIVE_ID, SMP_ACTUAL_POSITION_FB, &actualPosition);
if (result != SM_OK) {
fprintf(stderr, "Error: Unable to read the actual position.\n");
break;
}
#define SMP_ACTUAL_POSITION_FB_NEVER_RESETTING 906 /*this is same than SMP_ACTUAL_POSITION_FB but does not reset to 0 on homing or init (it is always the original counter value at power-on)*/```
I have to say that I find this ārelativeā behaviour of the IONI PRO quite surprising. You do not use a digital absolute sensor without a reason (they are more expensive and require a sophisticated interface), so my understanding is that position reading and setpoint should also be absolute.
If this parameter is in reference to the position at power on, I think it would be trivial to calculate the offset just once from the power-on position vs. the never resetting position and then continue from there.
Well, contrary to what its name suggests, SMP_ABSOLUTE_SETPOINT is absolutely relative to the power-on position.
Of course, I did the math relTarget = relPosition - absPosition + absTarget and it works.
but this looks somewhat weird (especially after I told the project team that thanks to our costly absolute sensor, we could aim at a setpoint the same way )
Also, for reading the absolute, then the relative position, it takes two non-simultaneous SM calls and the result will be impaired if the sensor is (even unintentionally) in motion. (ok, make a reading before, a reading after, take average value )
result = smRead1Parameter(bus, DRIVE_ID, SMP_ACTUAL_POSITION_FB_NEVER_RESETTING, &absPosition);
if (result != SM_OK) {
fprintf(stderr, "Error: Unable to get the absolute position.\n");
smCloseBus(bus);
return EXIT_FAILURE;
}
result = smRead1Parameter(bus, DRIVE_ID, SMP_ACTUAL_POSITION_FB, &relPosition);
if (result != SM_OK) {
fprintf(stderr, "Error: Unable to get the relative position.\n");
smCloseBus(bus);
return EXIT_FAILURE;
}
relTarget = relPosition - absPosition + absTarget;
result = smSetParameter(bus, DRIVE_ID, SMP_ABSOLUTE_SETPOINT, relTarget);
if (result != SM_OK) {
fprintf(stderr, "Error: Unable to set the target point.\n");
smCloseBus(bus);
return EXIT_FAILURE;
}