To elaborate my idea (no I did not invent this) the servo loop and pulse generation and all other "hard" real time is run on a 32-bit uP. The lops will run with nearly zero jitter as the timing is control from a divide down crystal clock. The loop does not do a command then say "I'm done". No. the loop just runs so many time persecond, forever.
The loops do need data. They need a target position or a target velocity. These targets are sent across an SPI (or I2C or Ethernet or,..) interface from a Linux machine. But you MUST de-couple the timing. Linux can not be feeding one target number at a time. One way to decouple is to use a queue or "buffer" The Linux machine sends the targt points faster then the phu=ysical milling machine needs then so that 20 or 1,000 targets are queued. Each target has a time stamp that tells the real-time loop when the target become valid. Also there might be more than one uP in the system. Perhaps the Machine is complex and has many switches and collent pumps and 6 axles. then maybe three of the uP to run the real-time loops. Actualy nothing changes, The same loops that now run under Linux could run on a uP. WHy move the loops to the uP? Because then you no longer need Linux to be real-tiime. and more impotently, you don't need Linux. Now that the PC side is the nonreal-time you can use any OS you like. Many people might like to run on Andriod or Windows or Mac OS. The "PC" could be a tablet. One of the functions of the PC/Linus side is flashing the STM32 uP. So users need not understand much about how the uP works On Mon, Mar 25, 2019 at 10:31 PM Rafael Skodlar <ra...@linwin.com> wrote: > On 3/25/19 8:39 PM, Chris Albertson wrote: > > Yes, you have to patch Kernels. I think this is the #1 weakness of > > Linux CNC. It would be good to eliminate the need for a real-time > Kernal. > > Patching is not a weakness IMO. This is done all the time. FPGAs for > example would get loaded with "binary blobs" during bootup to do their > things as programmed. Another way to handle this is with kernel modules. > Load modules for whatever a particular SBC needs. > > > How? Move the real-time parts to hardware such as the uP, PRU or > Mesa > > FPGA. Clearly, it can be done because people are controlling machines > > with only a uP, PRU or FPGA. > > Brilliant IMO! In this scenario, microcontrollers accept commands from > LinuxCNC for example and handle their tasks in loops or whatever program > flow until the task is finished then send interrupt back to main > processor board saying "I'm done". > > Subcontrollers could be advanced in some cases, a RaspberryPi or some > such running it's own Linux for specialized tasks: drive stepper motors, > read sensors, etc. > > Easier said than done I know, but better than do that all in RT kernel > to fiddle with parallel port and other silly obsolete things. > > > > > The interface was designed around a parallel printer port when outbound > > processors had poor performance andhad to be on custom PCBs. Today we > > have 32-bit STM32 uP on a board.The real-time code can move off the Linux > > PC. > > I like this idea. Kernel params can be tweaked so that certain processes > are 'niced' above the others. I remember tweaking kernel parameters long > ago for mouse, keyboard, etc. response time. Workstations one way, > servers that were not using keyboards and mouse most of the time > another. In this case, LinuxCNC would get highest priority over anything > else in the system for example. > > -- > Rafael > > > _______________________________________________ > 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
