> -----Original Message----- > From: Jon Elson [mailto:el...@pico-systems.com] > > On 01/21/2020 11:55 PM, Chris Albertson wrote: > > Yes. I would not blindly recommend any of the RTOSes without a doing a > > more detailed design of the application. Nutx might be better. They > > are VERY different from Linux. Linux boots of a disk that allows you to > > run other independent apps. This other class of OS must if linked in with > > the application code and when the machine boots it will only run that code. > > one does not bot an RTOS then run an app, rather the ROS is a library that > > you apps links to. > > > I find it very useful to have my CNC control on my local > network. I have hundreds of often-used > toolpath programs on it, and back it up every once in a > while. Also, I can generate new > toolpaths on CAD systems and download them to the CNC computer. > > Jon >
What a fascinating discussion. Be prepared. What follows is pretty long. Takes me back to the mid 80's when I wrote our own RTOS for the NEC 78C10 series of micro-processors. Or even earlier when I wrote code to move an XY gantry laser cutter system. The motion control code was all done in 8085 Assembler and specifically just to demo motion. Not accept programs; just move hardware. I believe it's important to separate the components of the system in the sense of describing what they do. Initially the 8080/Z80/6502/6800 based systems clearly separated the Basic hardware dependant I/O System (BIOS) from the System that Operated and interacted with the end user (the OS) and the software Applications (Apps) that end users used. Apple did a really good job of blending them all into one since they also supplied the 6502 hardware. Before the IBM PC the Micropolis DOS, Northstar DOS and CP/M could all be ported to different hardware although Micropolis and Northstar both used proprietary disk drive hardware. Seattle Computer Products DOS-86 was out just before CP/M-86 for the 8086 S-100 bus computers. And needing a vehicle for his Basic Interpreter, Microsoft quickly purchase DOS-86 renaming it to MSDOS 1.0 and sold licenses through IBM for the new 8 bit version of the 8086. (8088). Meanwhile on the minicomputer side was Unix (I wrote graphics software on a PDP-10 in University) but for the most part that was still all terminal based. Graphics were limited. And then along came the APPLE MAC. And shortly after that WIN-286, WIN-386, WIN-3.0 and finally the one that lasted for a while WIN-3.1. My time then, from 1992 to 1994, was spent writing software for an OS9-68K (upgraded OS9 for the 16 bit 68000 processor like the one used in the Apple MAC). EMAC editor until I convinced them to give us PCs so we could edit the programs using CodeWright from Borland. Visual editing that detected CR or LF or Both for end of lines. Syntax highlighting. Etc. Via serial port we still compiled on the OS9-68K system and then burned EPROMs to take out onto the shop floor to insert into the equipment. Somewhere around this time Linux showed up along with the GNU (GNU is Not Unix). And with the various Linux flavours (and books) regardless of the open software concept, only the most expert and dedicated could port to new hardware. Far more difficult than an MP/M-86 port I did in the 80's. Complexity aside, Linux has probably kept the hardware, the OS and the User Interface more separated than any other system. So now what does that have to do with LinuxCNC (formally EMC) The real time nature of machine control means that an event needs to be responded to within a specific amount of time or the event becomes an error. In the past when any retrofitting to CNC (Computer Numerically Controlled with punched paper tape) the motors ran with +/-10V signals and fed back position with resolvers or encoders. The control was all hardware and with EMC that was moved into the PC. That's why you still see proponents of these systems stating the best place for the closed loop is in the actual PC generating the G-Code. Because LinuxCNC could produce a voltage and read the encoder and close loop PID control the motor. But the advent of inexpensive stepper motors that were reliable enough, when not overloaded, to run open loop changed the game for everyone. The interrupt driven device driver for MACH2 and then MACH3 using the simple parallel port and only step/dir signals changed the world. Retrofitting big commercial mills still required closed loop at some point and although, over the years we've seen a number of Servo/Encoder/Resolver units with fault outputs if motion is incorrect, for many systems closing the loop inside LinuxCNC was the only solution. Meanwhile the 3D printing world, with 8 bit micro-controllers doing extremely fast step/dir of lightweight motors, has changed the perspective of what is needed for CNC in general. The loss of the parallel port on PCs now requires that add on card that a decade ago was considered way too expensive now appears to just be another cost. Or maybe not? What exactly is a CNC system supposed to do? Does it need a GUI (Graphical User Interface)? Certainly the 3D printers don’t have them although I rarely look at the two line character display on mine. Mostly I use OctoPi written in Python, running as a WEB application via WiFI to a different room. Sophisticated enough so the Raspberry Pi2 Camera can provide what feedback is required. And the Pi is still talking to a small 8 bit micro-controller via a USB port. So why has Machine Tool CNC stayed with PCs? It's because they can be easily swapped. If you were using a custom ARM32 processor with all the I/O for +/-10V and encoder feedback for that old set of servos and the unit failed unless you have a spare board it's quite possible that you now have an orphan. But the motor controllers are now sophisticated ARM32 processors themselves (STMBL has two). Inexpensive user interfaces in the form of tablets with touch screens or are dropping in cost. So what's left? The future of CNC will go in the same direction whether we like it or not. The CNC engine. The one that reads G-Codes and sends out commands to the axis will become a block and quite likely will have 32 bit processor and RTOS. It might even have a small 4x40 line diagnostic display with a button and a rotary knob to access menus. And like the STMBL servo drive, which with the correct configuration files can run all sorts of motor combinations, the block that does the G-Code to messaging will be the same. Likely won't be LinuxCNC although there's no reason it couldn't as long as it ran the real time versions. And all in a small 100mm by 100mm x 20mm box. If it's got an Ethernet connection (or USB3) then a laptop/tablet becomes the user interface. Common code that runs on Windows or Linux (no longer LinuxCNC much like OctoPi) The issue then is what 100mm x 100mm x 20mm block. And there's the catch. Machine tool lifetime is often measured in decades, not 3 year planned obsolescence cycles. And as long as PCs are still around with a common architecture, they will probably remain the building block. It's just a matter of separating the processing of the motion control commands from the hardware on one side and user interface on the other side. IMHO. John Dammeyer _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
