On Wed, 29 Apr 2020 at 01:35, John Dammeyer <jo...@autoartisans.com> wrote:
The important constants come from the INI file: > Note that they don't have to. A very simple LinuxCNC configuration can omit the INI. But once you loadrt motmod, then you need an INI to pass it the axis data. Is the real time component of Linux CNC running all the tasks that are > started with the loadrt with a 24uS period? In other words all loaded > "loadrt tasks" have to finish within 24uS or the system will start to have > jitter or miss events. > No, only the functions that are addf-ed to the base-thread run at that rate. Everything else (addf-ed to the servo-thread) runs at the servo-thread rate. This typically includes motion and the management section of many components. So, for example, the stepgen has a servo-thread part that calculates the step rate, and a base-thread portion that _only_ makes steps. Generally nothing in the base-thread does any floating-point calculations. (base-thread FP used to be disallowed, in fact, but can now be turned on via a switch) > setp stepgen.0.steplen 1 > setp stepgen.0.stepspace 0 > > Both values inside the motmod and parallel port tasks appear to set it to > that value or the minimum BASE_PERIOD. Whichever is shorter. At least > that is how I interpret it. > Is that correct? What that would mean is that although it wants a 1nS step length the > reality is the minimum period is 24uS and since a step pulse is exactly > that, a pulse, the step space is also 24uS. So that implies the fastest > step rate possible is 24uS ON and 24uS OFF or 48 uS minimum period which > gives a 20.833kHz stepping rate. In general yes, but the parallel port is a special case. It has a "reset" function that can be configured to switch pins back to their default state in the same thread cycle as the parport-write. (The parport reset will actually busy-wait if the time has not yet elapsed, so it is more efficient to put some other base-thread tasks between parport-write and parport-reset in the base thread to avoid waiting, except in cases where you need the parport pulses to be as short as possible (which I can't think of a use-case for) For a stepping motor driver with 10uStep per step that's still pretty well > faster than it can actually turn. For a Servo motor with a 2500 line > encoder it's way too slow so a step multiplier or encoder divider would be > required. > Step rate is not often a problem with the parport, encoder-counting hits the limit a lot more often. Especially on spindles. Now the trajectory planner. Am I correct when I interpret that the > trivkins planner runs at the BASE_PERIOD rate every 24 uS but uses the > SERVO_PERIOD of 1mS (1000000nS) for trajectory updating. > No, everything bar the most basic pin-manipulation functions tends to run at the servo-thread rate. (as you can see from typical HAL files) But back to my final question for this post. Is the Servo Period the time > interval used to calculate the next motor velocity? > So the acceleration is actually based on changing the velocity every 1mS > for that 1000000nS SERVO_PERIOD value? Yes. The acceleration and velocity curves are all governed by a set of _position_ waypoints that are updated every 1mS and sent straight to the joint.N... HAL pins. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
