STMBL pseudo absolute resolver behaviour
- Freak
- Offline
- Senior Member
-
Less
More
- Posts: 45
- Thank you received: 32
09 Sep 2023 11:04 - 09 Sep 2023 11:17 #280328
by Freak
STMBL pseudo absolute resolver behaviour was created by Freak
I was wondering if it is possible to skip the homing procedure involving machine movements having the position.txt file and the resolver of the stmbl, similarly to #116065 .
The stmbl use the linrev component to scale the radiant angle from the resolver to linuxcnc (available as sserial.pos_fb pin).
The stmbl linrev code is here:
So when I close the machine I still have the information of the angle of the resolver as sserial.pos_fb pin/scale*2pi.
I don't know how I can implement in linuxcnc the correction of the previous position in the position.txt file given the resolver angle...
I can see few options:
1. Store the last position in the stmbl, so when jogging directly in the stmbl I don't loose the position, but that would require an F ram and digging more inside the stmbl firmware...
2. Send the position.txt info to the stmbl using the sserial.pos_cmd and implement the correction and offset logic inside the stmbl (the sserial communication is limited, I can use only existing float pins)
3. Create a script in linuxcnc (I don't know where) that computes the correction and set the correct HOME_OFFSET value.
If I understood correctly the approach in the hostmot2 driver updates the position pin in the resolver component with the position.txt info (hal.pin.joint_pos_fb), so being now an absolute sensor, linuxcnc complete the homing by setting the home_offset as the resolver position.
What do you think is the best approach? I know that the developers here may have a much clearer idea of how to implement this feature.
The stmbl use the linrev component to scale the radiant angle from the resolver to linuxcnc (available as sserial.pos_fb pin).
The stmbl linrev code is here:
int q = quadrant(PIN(fb_in));
if(q != 0 && q == 3 && ctx->lastq == 2) {
ctx->rev++;
}
if(q != 0 && q == 2 && ctx->lastq == 3) {
ctx->rev--;
}
ctx->lastq = q;
if(PIN(rev_clear) > 0) {
ctx->rev = 0;
}
PIN(rev) = ctx->rev;
PIN(fb_out) = ((PIN(fb_in) + ctx->rev * M_PI * 2.0) * scale) / (2.0 * M_PI);
PIN(fb_d_out) = (PIN(fb_d_in) * scale) / (2.0 * M_PI);So when I close the machine I still have the information of the angle of the resolver as sserial.pos_fb pin/scale*2pi.
I don't know how I can implement in linuxcnc the correction of the previous position in the position.txt file given the resolver angle...
I can see few options:
1. Store the last position in the stmbl, so when jogging directly in the stmbl I don't loose the position, but that would require an F ram and digging more inside the stmbl firmware...
2. Send the position.txt info to the stmbl using the sserial.pos_cmd and implement the correction and offset logic inside the stmbl (the sserial communication is limited, I can use only existing float pins)
3. Create a script in linuxcnc (I don't know where) that computes the correction and set the correct HOME_OFFSET value.
If I understood correctly the approach in the hostmot2 driver updates the position pin in the resolver component with the position.txt info (hal.pin.joint_pos_fb), so being now an absolute sensor, linuxcnc complete the homing by setting the home_offset as the resolver position.
What do you think is the best approach? I know that the developers here may have a much clearer idea of how to implement this feature.
Last edit: 09 Sep 2023 11:17 by Freak.
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23314
- Thank you received: 4861
09 Sep 2023 17:26 #280338
by andypugh
Replied by andypugh on topic STMBL pseudo absolute resolver behaviour
One way would be a HAL component that takes the position feedback from the STMBL and the initial position from LinuxCNC, then computes the absolute position and then lies to the rest of the system about it.
This is actually what I did before integrating it into the driver.
Though my memory is vague, and it is possible that I integrated it into the driver as it worked better that way.
I might have the HAL component somewhere, still.
This is actually what I did before integrating it into the driver.
Though my memory is vague, and it is possible that I integrated it into the driver as it worked better that way.
I might have the HAL component somewhere, still.
Please Log in or Create an account to join the conversation.
- Freak
- Offline
- Senior Member
-
Less
More
- Posts: 45
- Thank you received: 32
09 Sep 2023 18:47 #280343
by Freak
Replied by Freak on topic STMBL pseudo absolute resolver behaviour
Thank you Andy, If you still have the code for that components would be very helpful.
I think that in the future saving the information inside the stmbl is a better solution, as you did in the mesa driver, the only difference is that the stmbl cannot access the linuxcnc hal components so it need a place where to store the position every time it engage the motor brake.
That requires a new revision of the hardware with an f-ram onboard.
For now a workaround is enough.
I think that in the future saving the information inside the stmbl is a better solution, as you did in the mesa driver, the only difference is that the stmbl cannot access the linuxcnc hal components so it need a place where to store the position every time it engage the motor brake.
That requires a new revision of the hardware with an f-ram onboard.
For now a workaround is enough.
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23314
- Thank you received: 4861
10 Sep 2023 09:42 - 10 Sep 2023 09:42 #280386
by andypugh
Replied by andypugh on topic STMBL pseudo absolute resolver behaviour
It appears that I used a python component, and that it uses its own .var file rather than position.txt
It seems to output an offset, which I assume I added to the encoder feedback using a realtime component (probably sum2)
I don't recall the full details, it was an experiment 5 years ago.
It seems to output an offset, which I assume I added to the encoder feedback using a realtime component (probably sum2)
I don't recall the full details, it was an experiment 5 years ago.
Last edit: 10 Sep 2023 09:42 by andypugh.
Please Log in or Create an account to join the conversation.
- Freak
- Offline
- Senior Member
-
Less
More
- Posts: 45
- Thank you received: 32
10 Sep 2023 12:01 #280392
by Freak
Replied by Freak on topic STMBL pseudo absolute resolver behaviour
That makes totally sense, and I think it is the easier way, I can try to use the hal.pin.joint_pos_fb before homing instead. Thank you very much, I'll post the results soon.
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23314
- Thank you received: 4861
10 Sep 2023 15:59 #280405
by andypugh
Replied by andypugh on topic STMBL pseudo absolute resolver behaviour
Are you aware of the various options for absolute encoder setup?
linuxcnc.org/docs/stable/html/config/ini...t__lt_num_gt_section
HOME_ABSOLUTE_ENCODER
linuxcnc.org/docs/stable/html/config/ini...t__lt_num_gt_section
HOME_ABSOLUTE_ENCODER
Please Log in or Create an account to join the conversation.
- andypugh
-
- Offline
- Moderator
-
Less
More
- Posts: 23314
- Thank you received: 4861
10 Sep 2023 16:01 #280406
by andypugh
Replied by andypugh on topic STMBL pseudo absolute resolver behaviour
And, I guess that the Python HAL component, once it has done the calcs, could automatically issue the home-all command:
linuxcnc.org/docs/stable/html/config/pyt...command_code_methods
linuxcnc.org/docs/stable/html/config/pyt...command_code_methods
The following user(s) said Thank You: Freak
Please Log in or Create an account to join the conversation.
- Freak
- Offline
- Senior Member
-
Less
More
- Posts: 45
- Thank you received: 32
10 Sep 2023 17:29 - 10 Sep 2023 17:31 #280415
by Freak
Replied by Freak on topic STMBL pseudo absolute resolver behaviour
Yes I'm aware of the homing setup for absolute encoders, thanks, for now I've been able to run your component, now I'm trying to check if it works correctly. After I want to try using the hal.pin.joint_pos_fb and see if it can work, so making the pseudo_abs_encoder.var not necessary.
Last edit: 10 Sep 2023 17:31 by Freak.
Please Log in or Create an account to join the conversation.
- Freak
- Offline
- Senior Member
-
Less
More
- Posts: 45
- Thank you received: 32
11 Sep 2023 15:34 #280482
by Freak
Replied by Freak on topic STMBL pseudo absolute resolver behaviour
The component is not working well because the stmbl's don't reset the internal position when linuxcnc closes, so I added the following:
[code]
p = h
p, _ = math.modf(p / s)
p = p * s
[\code]
So if the resolver shows more than one turn, then I take only the angle information.
I'll try now to use the position.txt
[code]
p = h
p, _ = math.modf(p / s)
p = p * s
[\code]
So if the resolver shows more than one turn, then I take only the angle information.
I'll try now to use the position.txt
Please Log in or Create an account to join the conversation.
- Freak
- Offline
- Senior Member
-
Less
More
- Posts: 45
- Thank you received: 32
25 Sep 2023 12:51 #281595
by Freak
Replied by Freak on topic STMBL pseudo absolute resolver behaviour
Hi, here is the working component for the stmbl with a resolver.
I tested and since now it's working very well.
I had to replace the angle correction logic based on the angle quadrants as implemented in the stmbl.
I tested and since now it's working very well.
I had to replace the angle correction logic based on the angle quadrants as implemented in the stmbl.
Please Log in or Create an account to join the conversation.
Time to create page: 0.093 seconds