On Monday 30 October 2017 04:22:06 Chris Albertson wrote: > The whole _point_ of EMC was to do the realtime on off-the shelf > > > general purpose computers rather than on specialised hardware. > > Yes, that was the point. But look today people are building systems > using a $35 ARM based "PC connected to a $100 FPGA board and then to > a couple hundred dollars worth of servo drivers.
i think you are talking about me, since I seem to be the only perpetrator of a $35 r-pi running a moderately serious lathe. One of the things of note is that exposing the relatively cheap 7i90HD to the electrical noise generated by a vfd and the stepper drivers is guaranteed to blow the i/o on the 7i90HD. So while I am doing it, I found that putting the pi and the 7i90HD in its own box did a pretty good job of controlling the noises, it was also a very good idea to buffer the 7i90HD's i/o with a 7i42TA, at just under an additional $50 bill times 3. So $$35 for the pi, $65 for the 7i90HD, and about $140 for the 7i42TA's, and I'm finally ready to issue steps to a $40 2M542 for x, and an $80 DM860 for the z. Add in another $150 for the psu toroids and filter caps to make the motor psu's, $125 for a 1.5 hp rated vfd, and $50 for a pair of 1 hp 3 phase motors, one of which got fresh bearings and is in the bottom of the pedestal now. So I've got lots of cash in this. But lets break that pi into 2 pieces. One, thats part 1 running the lathe, is doing a great job despite the fact that there is not a pid module anyplace in its configuration! All of its i/o goes in and out of linuxcnc thru an spi bus, writing at 41 megabits, and reading at 25 megabits. Part 2 is the keyboard/mouse interface that has to contend with all the other i/o on the pi thats stuck being funneled thru a usb2 internal hub, and it drops keyboard events in wholesale quantity's. Its reboot sensitive, so usually, several reboots are required before the keyboard works well. And once its working, it generally keeps on working for quite respectable uptimes. Thats a pi internal hardware problem that a rock64 doesn't have. There are 2 problems to be addressed before a rock64 can replace the pi. 1. I've not figured out how it boots, so I have no clue how to go about replacing a sim only kernel with a realtime I have built directly from a git pull of the rtai git repo. That it turned out was relatively easy, and only about an hours worth of cpu on the rock64 to do, where the same kernel, built on the pi, would likely take a day or more since its bandwidth to storage, whether SSD or spinning rust, is so damnedly slow. 2. Bertho put code in rpspi.ko that checks to make sure its running on a pi. And I've not successfully excised that code, nor replaced the pi's gpio related headers with the rock64's version, so I don't have a driver for the 7i90HD that runs on the rock64 yet. This is complicated by my not having a clue how to copy rpspi.c to rkspi.c because the act of copying it apparently blows git's mind and it now refuses to do anything, like stay uptodate with the linuxcnc.git repo. > The cost has > flipped. The external specialized hardware (Mesa card) costs 3X more > then the PC. And the gecko-style drivers even more. Actually if yu > loud to single digits al that i left is the specialized external > hardware. Nothing wrong with this just commenting one how far > current usage is from the initial design goal. Time marches on Chris. The formerly most costly item, the pc, has gotten to be a $44 credit card sized thing that loses 35 lbs at the same time. Thats how much a rock64 with 4GB of ram costs today. And its quad core, running at 1.5GHz, which beats the atom boards rather nicely. And has gigabit ethernet and USB3 although we'll need a usb-3 hub because its only one port, the other 2 are USB-2. And no radio, which it turns out turning that off helps the pi. > > LinuxCNC is a machine controller that runs everything on one general > > purpose PC. That might not be the optimal way to do it, but if you > > want to do it a different way then I don't think that LinuxCNC is a > > good place to start. But its versatile enough to do it. > LinuxCNC has excellent parts A g-code interpreter and a motion planner > and a flexible way to tie it all together. > > I think the current trend in the industry is to move the control > loops closer to the motors. There is good reason today to do this. > In the old days computers were expensive so you wanted to use just one > of them. Today they are nearly free. In fact I can by a STM32F on a > PCB for less than the price of a good power cable. > > Today the cost of "specialized external hardware is near zero because > it can be created simply by programming a general purpose board like > an Arduino or its more modern equivalent. > > What I'm looking into is a distributed system with computing pushed > closer to where it is used. Grapical stuff should happen on a GPU > connected to the monitor. Servo lop can be close on the motor > > > GRBL might be a good place to start, or some other uP-based > > controller. > > GRBL is not a distributed system. It really is the old EMC design > where everyone runs on one computer. Its problem is that it > sacrifices generality so it can run on the very low end computer. > > I don'tsee a reason to use a micro controller except for battery > powered devices or if you need to talk to hardware pins. A laptop PC > would be ideal Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
