Oh I just can't resist. > -----Original Message----- > From: Rafael Skodlar [mailto:[email protected]] > On 2020-02-11 01:04, Chris Albertson wrote: > > I said people *want* to use CNC like a laser printer. Most setups are > > not that good. It is a goal and if designing a new system. It is good to > > set the bar high and try to do what can't be done today. What I really > > meant was that with a printer, all the critical timing happens in the > > printer. There are no servo-loops on the PC and you don't need a real-time > > OS to print to paper. I think people want CNC to work this way. > > > > That's how some CNC machines work. I came across a small woodwork > business owner with very nicely garage that was converted into workshop. > Win PC in the corner for designing parts in CAD, large Axiom CNC machine > with a pendant to control it. Tiny LCD is all that's needed to select > the job, i.e. file from a USB stick. > > The owner did not know what's inside the CNC machine itself and he > doesn't care. That's what you say Chris I think and I agree with. > >> > >> https://www.machinedesign.com/3d-printing-cad/article/21122653/top- > 11-myths-of-cnc-machining > > the article states: > Myth #4: G/M Code is a Thing of the Past > > That's true too. It amazes me that the industry did not go away from > primitive code by today standards. G-code was only modified or updated > by some CNC machines manufacturers as far as I know but most of G-code > is still the same. Compare that to computer/software advancements since > 1980s. Perl, php, python, Go, html, etc.
I don't think I'm on the same page with you. If you want to compare the 1980's with your list of high level languages please compare mechanical drawings done with pencil and drafting table against Fusion360, SolidWorks, AlibreCAD/CAM and some of the other dedicated software that CNC shops use. In one of my products I use a M9S12XDP512 processor. What is that you ask? It's really not a lot different from a M6809 which isn't that different from an M6800 or even a 6502 which was the original processor in the Apple-II or the Comodore 64. The 9S12 is more advanced with a 16 bit register and paging so it can deal with 512K of flash memory and 32K of ram not to mention 5 CAN ports. I write the applications in C and when needed take a look at the assembler generated by the compiler. I do the same with the dsPIC30F series from Microchip. Sometimes you just have to look at the assembler output to make sure the compiler is doing what you expect. A slight change in the C language makes a world of difference in what the compiler generates and affects the speed or memory size. It's what I don't like about the Arduino or Python for that matter. Short of trying some benchmarks you have no idea if what you write is optimal. You can't look under the covers. With the high speed of processors now there's an approach that has become more common. The programming language compiler doesn't generate code for the host processor. It generates it for a pseudo machine. Then each processor or microcomputer has a program that simulates that pseudo machine in their own machine code. You only need one compiler like Python that generates that intermediate code, which is then interpreted by the implementation hardware. That's what is happening in the CNC world. We do our drawing in our favourite CAD package. We submit it to the CAM package. The CAM package generates the pseudo code (G and M codes). The processor interprets these codes turning them into physical operations. Even if you decided to generate a different pseudo code that was theoretically more 'modern' the reality is that eventually they have to be interpreted into physical operations. Create a large number of pseudo code languages and you're right back into the Intel/Motorola wars between the 80386 and 68000 families. Eventually Intel won since MACs now no longer use the 68000 etc. What I mean is if you have a command line and you type in Add 5 + 3 it spits out 8. That it's done with a 6809 or 68000 or 80386 or Pentium 66 doesn't matter. The CNC mill cuts from point A to point B at a specific velocity with the spindle turning a requested speed while the coolant floods the work. When done the spindle retracts and turns off, the coolant is turned off. So the idea that G/M codes are archaic is wrong. It's just the low level language interpreted by the controller. That controller then creates yet another level of messages or signals that make motors turn. And even that can have a layer of abstraction. But, and it's a big but, the actual discussion is really more about what part of the picture belongs where. Under Linux there are a number of different X window environments, all sort of the same but not. Under Microsoft Windows, you just have to wait a while and a new graphical user interface shows up. If you want the old one it's really too bad. Like WIN-7 discontinued in January. For Machine control we have: CAD -> CAM -> G-Code -> Trajectory Planning and implementation -> Ethernet OR Parallel Port OR PCI bus -> Step/Dir OR Smart Serial OR CAN bus or Ethernet. -> Hardware motion. Ask then which parts require a large PC with graphical interface? Which require pseudo real time? Which require hard real time? At the moment a PC compatible with a parallel port can do it all. Up to the latency measurement and then it can't reliably create the high speed stepping pulses. The OS is not important. LinuxCNC or MACH3 on WIN-XP/7. On both systems the CAD->CAM can also be hosted although it appears most LinuxCNC people still tend to use Windows for the CAD side. Now exceed the capabilities of the PC compatible and you are into the netherworld of FPGA/RealTimeProcessors to do the next step. And those aren't all public domain and certainly, like a PC wth a parallel port, totally interchangeable. My two cents. John Dammeyer _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
