I agree there are all sorts of ways of doing this. Only Peter at MESA or perhaps Jon could explain what they do but I don't know if it's proprietary to their hardware.
LinuxCNC knows the accel rate of the motors. Take for example the Parallel port version. setp stepgen.0.position-scale [AXIS_0]SCALE setp stepgen.0.steplen 1 setp stepgen.0.stepspace 0 setp stepgen.0.dirhold 45000 setp stepgen.0.dirsetup 45000 setp stepgen.0.maxaccel [AXIS_0]STEPGEN_MAXACCEL There's an assumption that regardless of the type of motor that the motor can keep up with this. If not then in the case of a stepper motor it will lock up and make noise. In that open loop mode something will eventually crash. For a DC Servo it the acceleration is higher than what he motor can do eventually the number of steps in won't match the encoder and when the overrun threshold is reached the motor will fault and halt the system if it's wired that way. The hal file values determine the step rate for a given inches per second or mm per second as determined by the G-code F parameter. Simple trig determines what the X and Y values will be to follow the hypotenuse of the target speed. A bit more math will determine how far both X and Y move while accelerating and decelerating to create the move along their hypotenuse. Remember the point is to move the correct distance, and, maintain as best as possible the target speed. That's using a method called exact stop. The assumption is that each move is an independent move with a start and end position. But when you do that the milling cutter slows down and stops changing the SFM and chip load. Then it has to accelerate up to speed again in the new direction for the next move. Very jerky if you are milling an arc. An alternative method is constant velocity. Now at each corner the XY motion is adjusted so the change in direction is a curve that maintains the X and Y motion such that the combined velocity remains as close as possible to the original F Parameter. This doesn't result in square corners but then a mill cutter isn't square so it's not such a big deal. And the XY axis never really stop so the machine shakes less. So now you have a clear set of way points for each change in velocity within the distance parameter. Next if your maximum step rate is 25kHz that's a step every 40 uS. If the step length is 5 uS you need to assert the step, wait 5 uS and then remove it. If the direction changes there are extra time delays involved: dirsetup; dirhold. And the system values BASE_PERIOD and SERVO_PERIOD drive how often the code deals with these step length and dir numbers. How does that translate to hardware. Well if there's a step every 40uS (25kHz) then you can have an 16 bit unsigned integer array that is 25k words long. And the array words are an image of the Parallel Port step and direction bits. 10 of those bits represents 5 axis. All the stepper engine has to do now is once every 40 uSec read a word out of the array and write it to a port. Then increment a pointer wrapping around. In reality this would be a structure with more information like start of accel, move, end of accel, for each axis, but for now just think of it as a simple array. For an RTOS based machine a task would be set to wake in 5 uSec (Step length) and its sole purpose would be to clear the step bits in that image and write that out. Or grab a timer value, add the step length and then wait for the timer to roll past that time and clear the step pins. Now you've created a step pulse. It's a dumb engine. It has no clue what it's doing. The trajectory planner filled in this array of step/dir information. If you are dealing with intelligent drives they are then told to do sequences of moves based on perhaps acceleration/velocity/distance. The whole point is the acceleration is known. The velocity is known. The distance is known. The rest is simple linear algebra to create a series of velocity with acceleration commands that keep the XY moving along the target trajectory Change to a 5 or 6 axis robot arm and all that changes is the size of the array use for the linear algebra geometric calculations for position in space and how to get there. I don’t know what LinuxCNC does since I've not looked at the code. But one second is a really long. If you can guarantee that the update interval is 40 milliseconds you only need 1000 possible steps stored and/or calculated for a 40 kHz step rate. Less if you are sending out way points with desired accel/velocity/distance to each motor. The LinuxCNC trajectory planner is already stable and working. And not really hard real time as long as you can fill a ping pong buffer within every 40 milliseconds or so. Or however big it is. An Ethernet TCP/IP packet is 1550 bytes IIRC. So along with motion overhead parameters one packet every 40 milliseconds is loafing for a 100MBPS Ethernet. If you've followed all this you can see that the intelligence is in the trajectory planner. There is no need to replace that part of LinuxCNC into a dedicated stepping engine RTOS driven module. It's just a matter of configuring the results into a form that is interpreted by the hardware that talks to the motors. I think I've said the same thing Chris did but from a different perspective. For my ELS I used the Bresenham algorithm https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm to move Z relative to the spindle for threading. After all, a thread is really just a triangle wound around a cylinder. Move Z relative to the spindle and you move along the hypotenuse of a triangle. Each step pulse possibility examined a counter incremented by a constant based on spindle RPM and if it rolled over set the Z STEP pulse ON. At the end of the routine the STEP was set off. Based on the number of Z step pulses a similar calculation would set the X STEP pulse ON in order to do tapering. John Dammeyer > -----Original Message----- > From: Chris Albertson [mailto:albertson.ch...@gmail.com] > Sent: January-24-20 9:56 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] Real-time OS for machine controllers > > On Fri, Jan 24, 2020 at 8:29 PM Alan Condit <condit.a...@gmail.com> wrote: > > > Chris, > > > > If I send 10000 steps to a smart X-axis controller, how does it stay in > > sync with a smart > > y-axis controller without someone controlling the synchronization between > > the two? > > > > As said, "steps" are the wrong thing to send. What they do is send time, > tagged points. Each point has a time tag on it. It is not hard to > synchronize clocks at the microsecond level. > > What they send is a list of target points. Assuming the machine works in > (x, y, z) space each point, you have "time", (x, y, z) and (x', y', z') and > (x'', y'', z''). A machine might have more or fewer axis with different > names, but same idea. Each controller can handle up to some maximum > number of axis and it wold not be until you are over that limit that you'd > have to split things. Doing six axis on one controller is reasonable. > > The controller tries its best to hit the target points. It can happen that > a target is impossible. Also, some of ths data can be omitted. Doing so > wuld free the controller to do what it "wants". I think you always want > x,y,z but could maybe omit the prime (velocity) or double prime > (acceleration) This kind of path planning is what LinuxCNC already does, > but today it is reasonable to push this down into a $5 chip. > > LinuxCNC is originally written used the exact oposite aproach and move all > the "smarts" upstream into a PC. > > The non-real-time part has to read the g-code or the conversational > interface or the hand pendant or video data and convert to a stream of > target points. > > That said, "steps" could work if each one had a time tag. But that pushes > the planning upstream and I think the better plan is to move as much > "smarts" as possible as close to the physical motor as possible. So let > the motor driver figure out what rate to drive each otor so the targets are > reached. > > > > Alan > > > > > From: Chris Albertson <albertson.ch...@gmail.com> > > > Subject: Re: [Emc-users] Real-time OS for machine controllers > > > Date: January 24, 2020 at 9:48:27 AM PST > > > To: "Enhanced Machine Controller (EMC)" <emc- > us...@lists.sourceforge.net > > > > > > > > > > > > If you can tolerate latency, then your "hub" does not need what we call > > > "hard" real-time capability. It only needs to keep up with the average > > > workload, averaged over whatever latency you can tolerate. Video > > streaming > > > works this way. They can't reliably send video and the 60 Hz frame > > rate > > > so they buffer a few seconds of video on your phone and the real-time > > > viewer lives on the phone not the server. > > > > > > g-code could be the same way. The penalty is that when you press the > > "go" > > > button the milling machine would take a few seconds the start working > > while > > > the data buffers into the low-level motor controllers. Today a > > > step/direction controller has no memory so it must be fed steps in real > > > time. But if it has a 10,000 step memory you could just transfer blocks > > > ever half second and the controller would work down the queue. > "Steps" > > > are the wrong kind of data for this but "states" are what is used. > > > > > > You are correct in that some real-time ability is needed at every level. > > > But we could design things so the requirements are VEY loose at the > > highest > > > level for 0.5-second latencies being acceptable. One you need only > > that, > > > then even an iPhone is a good enough platform. > > > > > > On Thu, Jan 23, 2020 at 11:32 AM Peter C. Wallace <p...@mesanet.com> > > wrote: > > > > > >> On Thu, 23 Jan 2020, Chris Albertson wrote: > > >> > > >>> Date: Thu, 23 Jan 2020 10:17:44 -0800 > > >>> From: Chris Albertson <albertson.ch...@gmail.com> > > >>> Reply-To: "Enhanced Machine Controller (EMC)" > > >>> <emc-users@lists.sourceforge.net> > > >>> To: "Enhanced Machine Controller (EMC)" < > > emc-users@lists.sourceforge.net > > >>> > > >>> Subject: Re: [Emc-users] Real-time OS for machine controllers > > >>> > > >>> The trouble with the Mesa FPGA design is that it depends on a > computer > > >> with > > >>> good real-time performance. It can generate steps but I don't thing > > you > > >>> can run a position or velocity PID control loop on the FPGA. > > >> > > >> LinuxCNCs design paradigm requires realtime, this is a design decision > > >> that is > > >> supported by our Hostmot2 real time firmware. We have other > firmware > > that > > >> implements motion in the FPGA but this is not suited to LinuxCNCs > model. > > >> > > >> > > >> You might argue that its an old fashioned model but many high > > performance > > >> CNC > > >> systems and Robotics controllers use LinuxCNCs model of a capable real > > >> time host > > >> (real OS with file I/O loadable modules, unlimited memory, massive > > >> floating > > >> point performance etc etc) Some of these use Linux and others use real > > >> time > > >> windows varients often with Ethercat Peripherals. This makes for a > > >> powerful > > >> extensible realtime toolkit (like LinuxCNCs HAL) and complex realtime > > >> responsive coordinated motion. Basically for this type of system you > > still > > >> need a very capable real time controller hub even if the motor > > controllers > > >> implement torque, velocity, or position loops > > >> > > >> > > >> Peter Wallace > > >> Mesa Electronics > > >> > > >> > > >> > > >> _______________________________________________ > > >> Emc-users mailing list > > >> Emc-users@lists.sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/emc-users > > >> > > > > > > > > > -- > > > > > > Chris Albertson > > > Redondo Beach, California > > > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > -- > > Chris Albertson > Redondo Beach, California > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
