Feature Request

More
30 Jul 2020 13:40 - 30 Jul 2020 13:40 #176512 by PCW
Replied by PCW on topic Feature Request
Sounds like somehow there is a step in the commanded position
that violates the machine maxaccel limits. It should be bounded by both
the stepgens maxaccel/maxvel settings and the pid maxerror settings

Would it be possible to plot the motor position command in halscope
to get an idea of what's happening here? (with a finger posed over Estop)
Last edit: 30 Jul 2020 13:40 by PCW.

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 13:42 #176515 by snowgoer540
Replied by snowgoer540 on topic Feature Request

Maxerror lines should be omitted or deleted on stepper systems.
Using sensors as end stops is not a good idea, hard stops should be where your sensors are and sensors should be mounted sideways.


Heinsight being 20/20, I concur. Of course it's only a problem when it crashes into them :)
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 13:44 #176517 by snowgoer540
Replied by snowgoer540 on topic Feature Request

Sounds like somehow there is a step in the commanded position
that violates the machine maxaccel limits. It should be bounded by both
the stepgens maxaccel/maxvel settings and the pid maxerror settings

Would it be possible to plot the motor position command in halscope
to get an idea of what's happening here? (with a finger posed over Estop)


Yes, it's definitely possible, if you tell me exactly what you want me to watch. I'm a noob when it comes to some of this stuff, but halscope probably isnt my strong suit.

I'm still confused on the pid maxerror settings. I keep reading things that seem contradictory (Tommylight just said they don't belong ona stepper system, but with what you just wrote, it seems like you expect it to be there). For a stepper system, should they be removed, or should they stay?

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 14:09 #176518 by PCW
Replied by PCW on topic Feature Request
Normally they are not needed if you have the DPLL enabled
Basically they prevent the PID from doing crazy things with
the stepgen velocity if the PID component gets bad information

How can the PID get bad information? if you have bad jitter
and you are not using the DPLL, the feedback position
from the stepgen will be sampled sometimes with a significant timing error
causing an error in the feedback position vs LinuxCNCs commanded
position. The PID acts on this bogus error and makes a large velocity
correction, worse case causing a stutter or stall.

The maxerror setting is redundant if you have the DPLL enabled

In this case, the maxerror is limiting the PID correction of what looks like
commanded motion from LinuxCNC that violates acceleration constraints

The LinuxCNC pins that I would watch would be:

joint.0.motor-pos-cmd (for X)
joint.1.motor-pos-cmd (for Y)

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 14:16 - 30 Jul 2020 14:16 #176521 by snowgoer540
Replied by snowgoer540 on topic Feature Request

Normally they are not needed if you have the DPLL enabled
Basically they prevent the PID from doing crazy things with
the stepgen velocity if the PID component gets bad information

How can the PID get bad information? if you have bad jitter
and you are not using the DPLL, the feedback position
from the stepgen will be sampled sometimes with a significant timing error
causing an error in the feedback position vs LinuxCNCs commanded
position. The PID acts on this bogus error and makes a large velocity
correction, worse case causing a stutter or stall.

The maxerror setting is redundant if you have the DPLL enabled

In this case, the maxerror is limiting the PID correction of what looks like
commanded motion from LinuxCNC that violates acceleration constraints

The LinuxCNC pins that I would watch would be:

joint.0.motor-pos-cmd (for X)
joint.1.motor-pos-cmd (for Y)


Thanks Peter! How would I know if I have DPLL enabled?
EDIT: I am not using an Ethernet based system, I have a 5i25 with a 7i76

And to be clear, you want me to scope those pins when the shutter movement occurs, or in the process that leads up to the shutter occurring?
Last edit: 30 Jul 2020 14:16 by snowgoer540.

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 14:27 #176523 by PCW
Replied by PCW on topic Feature Request
The DPLL will be enabled (for the stepgen) by something like this in your hal file:

# latch 50 usec before nominal read time:
setp hm2_[HOSTMOT2](BOARD).0.dpll.01.timer-us -50
setp hm2_[HOSTMOT2](BOARD).0.stepgen.timer-number 1

( The [HOSTMOT] and (BOARD) tokens make be the actual card name and 0
depending on how your hal/ini files were generated )

I would try to get a scope capture when the actual stutter occurs.
The following user(s) said Thank You: snowgoer540

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 15:24 #176530 by snowgoer540
Replied by snowgoer540 on topic Feature Request

The DPLL will be enabled (for the stepgen) by something like this in your hal file:

# latch 50 usec before nominal read time:
setp hm2_[HOSTMOT2](BOARD).0.dpll.01.timer-us -50
setp hm2_[HOSTMOT2](BOARD).0.stepgen.timer-number 1

( The [HOSTMOT] and (BOARD) tokens make be the actual card name and 0
depending on how your hal/ini files were generated )

I would try to get a scope capture when the actual stutter occurs.


I do not have those in my HAL file.

The only place I even have the word "time" in my hal is here:
setp    hm2_5i25.0.watchdog.timeout_ns 5000000

So should I add them? Again, I'm using a 5i25 (technically its a 6i25) with a 7i76, I do not have ethernet.

Attached my hal file for good measure.
Attachments:

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 15:34 #176535 by PCW
Replied by PCW on topic Feature Request
Normally the 5I25 configurations do not have the DPLL module as the access latency
tends to be better than Ethernet cards. Its possible to make 5i25 firmware with the DPLL
but standard configs don't have it.

I dont think its an actual issue unless you have quite poor latency (100s of usec)
on the host PC in which case you might get noise/stuttering all the time

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 16:22 #176538 by snowgoer540
Replied by snowgoer540 on topic Feature Request

Normally the 5I25 configurations do not have the DPLL module as the access latency
tends to be better than Ethernet cards. Its possible to make 5i25 firmware with the DPLL
but standard configs don't have it.

I dont think its an actual issue unless you have quite poor latency (100s of usec)
on the host PC in which case you might get noise/stuttering all the time


Interesting, so I guess that begs the original question of in a 5i25 circumstance, should I have the maxerror line then since I don't have DPLL?

I cant recall what my latency was off the top of my head to be honest, I am using the ethernet kernel so it's more than it would be with the other.

Please Log in or Create an account to join the conversation.

More
30 Jul 2020 23:21 - 30 Jul 2020 23:22 #176580 by snowgoer540
Replied by snowgoer540 on topic Feature Request

I just laid down to hit the hay

Sleeping on the job, we can't have that.:laugh:

I pushed some more changes, better feed rate calcs, better error handling and also it will restrict the travel for consumable change to 10mm (0.4") from all limits.

I don't think it will affect the stutter issue but I have something for you to try.
When you get to stage that you see the stutter issue, back away from the limit then in Halshow in this order:
  • put a watch on plasmac:offset-enable
  • unlinkp plasmac.offset-enable
  • sets plasmac:offset-enable 0
Notes:
two lines have a colon and one line has a period.
when you put the watch on, the led should have been on, then it should have extinguished when you did the sets command.

Now jog to the soft limits and see what happens.

Edit: you will need to net the plasmac.offset-enable pin to the plasmac:offset-enable signal to get the table to work again or restat LinuxCNC. (net plasmac:offset-enable plasmac.offset-enable)


Ok, so the shutter is still there. after updating.


  • put a watch on plasmac:offset-enable
  • unlinkp plasmac.offset-enable
  • sets plasmac:offset-enable 0

That worked the shutter was gone once I did those three steps.
However, after "net plasmac:offset-enable plasmac.offset-enable", it came right back.

Also worth noting, I did have my ini at X1 and Y1, so I'm not sure why only X has the stutter right now.
Last edit: 30 Jul 2020 23:22 by snowgoer540.

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.382 seconds
Powered by Kunena Forum