CNC daydreaming

[matthewsx]

The VMC has finally reached its intended destination, and is off the skates and back on the leveling feet. The chip tray on the right side is a little tight with the wall but it does come out. That's not going to be an issue for a while. I left plenty of room around back to work on the electronics. For now it is on the project list. First thing is to move my big granite CMM table/surface plate back into position. Then I'll need to run conduit w/ 3Φ to it to even test the old controller. I probably could boot that with just 220/110 if I wanted to jury rig something. I'll need to enhance my RPC to actually fully power this thing. I have a 20HP idler right now, probably will add a second idler, either 10 or 15HP, and stage them.

I did get a full image backup of the hard drive of the Acramatic 2100 controller, and I can loopback mount that on my linux box to check out the files. That was an 80GB hard drive apparently installed in 4/2004. The original drive was a 1.6GB hard drive, which had bad sectors, but I also backed up/recovered all but 8kB of that drive, those sectors wouldn't read. But at least I have copies of those. I'm not totally set on converting it to LinuxCNC if I can get the original controller working. It even has an ethernet card, almost certainly 10Mb since it has a BNC jack on it for thinnet in addition to an RJ-45 port. Of course a truly brave sole could try to install an old 32 bit Linux on the original controller, but linuxcnc drivers for the existing cards would be a challenge. I have not been able to find documentation on the internals of a Siemens Acramatic Controller, although I have not tried exhaustively.

Anyhow, I think it looks appropriate with the other 5000lb+ machines, modern technology offset by the little hand crank drill press on the divider wall. For now I'm back to scraping in my straight edge and working on the 12" rotary table automation.
View attachment 425266

Looking good

 

[rabler]

Looking good

Thanks. I would have held off a bit longer but it seems to be a pretty good project candidate and it was close, relatively easy to move. The previous owner had it in a small commercial space that he's looking to sell after buying a home in the country that has suitable space, so he was ready to sell it. He had found a deal on a newer used Haas that is in running condition. Nice guy, professional machinist but likes tinkering on his own too. Just doesn't have enough electronics background to really dig into troubleshooting older machines.

 

[rabler]

I contacted Mesa a few weeks back, Apparently they are redesigning several of their I/O boards after the chip shortage left them high and dry on FPGAs. I'm on the waiting list for a newer version of the ethernet card. Will be excited to get to work on that even though I have several other things going on in the shop to keep me busy. A LinuxCNC controller will be going in, but this will be a pretty extensive rewiring job. If I was just trying to get this thing to work, I'd try to revive the Siemens acramatic controller. I just can't get excited about owning something that runs on Windows NT 3.5/4.0. And detailed maintenance/repair documentation on that Siemens controller isn't readily available. .... Ok, I'm just a bit pusher and want to fiddle with it myself ....

 

[Shotgun]

You might want to look at the OrangePi5 as the controller. It took some fiddling with the ethernet interrupts to get the latency down, but I'm feeling good about it now. The driving force for me is the compactness of the package.

 

[rabler]

You might want to look at the OrangePi5 as the controller. It took some fiddling with the ethernet interrupts to get the latency down, but I'm feeling good about it now. The driving force for me is the compactness of the package.

I'll probably start with an old desktop machine, of which I have several, I can run a longer ethernet cable for testing. Eventually I'll probably use one of the small form factor machines of the variety like the Intel NUC or the many small-box solutions that are similar. Those are now available with 2 ethernet NIC's on the mainboard, and give plenty of CPU power to run the CNC side and also run a GUI and visualization apps. All of the RPI clones (ARM machines) are significantly lowered powered machines. Certainly more than enough to run a basic gcode controller, but I believe concurrent GUI's and apps will do better with a more powerful system. Cost wise, the $400-600 for a x86 in that class is not that much more than the ARM boards by the time you add everything needed (power supply, storage, RAM).

The VNC has a console cabinet, so my long term thought is to mount the small form controller up there with the monitor, keyboard, mouse, MPG, etc and run an ethernet cable from there to the full height electronics cabinet on the back of the VMC and mount the MESA board there. This will come after working out the control circuitry in the main (back) cabinet.

Obviously as you saw with the ethernet, throughput vs latency is a real issue. With CNC you want low latency when you're working with something like LinuxCNC that keeps the main CPU in the control loop. The fact that there are microcontroller based (Arduino, etc) G-code controllers is a pretty strong argument that throughput (compute power) is not a heavy need for g-code and motion control. Obviously most operating systems (Linux, Windows, etc) work on human timescales for latency. Us humans tend to see anything less than around 10milliseconds as "instantaneous". (You can argue that number somewhat, this is a ballpark). Driving a CNC machine quickly (rapid motion) but also accurately (sub thousands location) requires latencies that are 2-3 orders of magnitude faster. Most computers are optimized around that human reaction time. So getting the CNC response requires some work. Unfortunately each board/system/cpu/ethernet/etc is going to have some slightly different characteristics than need to be tuned. Just part of the challenge.

 

[Shotgun]

yes. The latency is what made the OPi5 attractive. During the initial testing, if I excluded running a YouTube video from the test, I was getting a max latency down around 2 or less. Running YouTube in the background resulted in some strange outliers out in the 25 range. I'm now thinking those outliers were due to the ethernet latency. So, I plan to bring it back in for further latency testing, this time with the IRQ locked to the CPUs that are running the real-time threads.

For those not in on the lingo. Latency is the difference between when a command arrives and when it is expected to arrive. Imagine you are injured, and require a blind man to rush you to the hospital. You're only able to get a word out with a lot of pain. So, you're limited to saying, "Left" or "Right", and the driver is expecting to turn exactly when you say it. In this case, giving the command too early is just as bad as giving it too late. But, how far out in the field on either side of the turn you'll end up is called the latency. The only way to account for a wide latency is to widen the road, which we do by expanding the time window that we wait for a command. But, that waiting, on. . . every. . . single. . . step, slows down the speed of the machine movement. Lower latency means a faster machine.

In this case, testing the computer showed that it would deliver the messages within 2ns of when it was supposed to. Forcing those communications to go through the ethernet cable was like requiring they be emailed to the driver via a web email service. He gets them. Most of the time. The window of when it might get there increase by a factor of 10. Locking the ethernet port to the CPU that was running the real time process changes it to using a local messaging system that is much more reliable. (How much more reliable requires more testing.)

 

[rabler]

To be really technical, it's actually the variation in latency that is problematic. This is called "jitter". If you are traveling 5 ft per second and know a command takes 2 seconds to process, to just give the command 10 feet beforehand. But if the command takes between one and three seconds to take effect, then your accuracy is at best 2 seconds or 10 feet.

In computers and networking, there are a lot of trade-offs. Simplifying one example trade-off: For a network connection you can create a queue to store things until they can get sent. If there is no room to queue something than that packet of information gets lost. Which dictates that those queues tend to be large. But large queues have high latency, and high jitter. There are similar tradeoffs in context switching, if the CPU checks what needs to be done (sending packets, etc) too frequently, it uses an increasing amount of overhead on just checking things and gets less efficient.

LinuxCNC tries to account for this, but the variation in hardware, both the computer itself and also the CNC machine hardware, creates some challenges.

 

[dkemppai]

Just a thought. Have you looked into the Kflops board?

I've always liked the idea of offloading the motion control to something dedicated. Kflops looks like a pretty powerful board for the price. I'm planning on ordering one just to play with, but haven't gotten there yet. The thought is to use that as the basis for a CNC surface grinder.

That said, I'm running flashcut cnc controllers. I really like them, and have been using them for over a decade now.
They're dedicated motion control is FPGA based, with a USB to the PC. Never ever had an issue with them. (Getting USB latency small is about tuning the software correctly. I do A LOT of USB hardware...).

I do have a USB smooth stepper on a cnc router. The hardware is exactly how I would build it, but the execution of the software/drivers for mach 3 have issues.
A while back I picked up some flashcut controllers used, and am going to upgrade that mill to a flashcut unit.

 

[rabler]

Just a thought. Have you looked into the Kflops board?

I haven't. I'm an old Unix/Linux hack dating back to the mid 80's. I ran a lab that used HP Unix machines supporting embedded programming with in-circuit emulators. I'm comfortable plowing around in the kernel and source code (just don't ask me about the latest desktop config, or whether or not this release uses systemd). More than once I've built my own Linux embedded install from source code up (although more than a decade since the last iteration). I've also tuned Linux for real-time use in software-defined radio applications, where a transceiver is interfaced via ethernet. That was coordinating an undergraduate student project plus co-advising a thesis student, that used time-of-arrival of packets to locate each unique MAC address in a football stadium, where a MAC address coorelates to a user's cell phone wifi. That gets into some much more challenging jitter requirements. So I have a pretty strong bias toward using LinuxCNC, both familiarity and as a refresher. The amount of stuff I've forgotten is depressing, I'm hoping to get my hands back into stuff I enjoy.

LinuxCNC tries to put itself into the real-time loop, which has some real challenges given all the crap an OS gets burdened with, but when it works achieves maximum flexibility from a high-level software functionality. The original LinuxCNC was bit-banged through parallel ports based on software timers. Looks to me like the high-end LinuxCNC is currently accomplished using FPGAs on break-out boards, with Mesa brand cards being the preferred (most supported) route, which is what I'm pursuing.

This gets pricey (as in not the cheapest approach). I expect to throw $500-600 into the computer, another $400-500 into the FPGA card and breakouts. That's before any interface circuitry, etc. It looks like the Yaskawa servos and spindle motor on the machine will interface well though, so I hope to not have to retrofit that hardware. I have yet to dig into the limit switches and encoders, but those are a lot cheaper than 15hp spindle servos.

I'm looking forward to the challenge, but I need to get the crane finished first. The VMC weighs about 8000 lbs, so the crane will be helpful just pulling off the outer shrouding and going over the wiring.

 

[dkemppai]

I only mentioned the Kflop board because it's designed as multi-axis a motion controller. Fully tunable closed loop servo or even stepper control. You have access to the PID loops, and can even write C style code into the design. Extremely customizable.

It's one of the solutions that gets you away from the CPU doing motion. IIRC it's around $250, and has a PC based CNC interface available.

One of the reasons I was interested, is that you can use a stepper or servo, and close the loop from a magnetic or optical scale with that hardware. Not sure many other controllers can do that. I believe Linux CNC can, tho. So it might not gain you much...