HAL integration with Arduino for slow/userspace data sharing

Hi All,

I'm thinking about connecting up an arduino to drive some RC servos and other silliness to achieve aim-able, remotely adjustable coolant nozzles. I realize that reaching to adjust coolant nozzles on a running machine is probably on of the biggest risks I take around my mill when I'm running it, and I'd like to reduce that risk some.

So, I realize that I could probably do something fancy with a 7i77 and a bunch of bumbling, but I'd like to leverage an arduino for ease of use. It seems there are a few different implementations out there over the years, userspace solutions using USB serial. Some possibly using modbus? SPI? I haven't examined all my options.

I'm looking for some thoughts on what my best course of action is. I'm fine with creating/modifying my arduino sketches to get the input/output flow I want and a bit less good at dealing with the component side of the house. So I'm looking for some advise on a jumping off point.

I'm planning to locate the arduino nearer the servos than the PC, and USB cables just don't seem very robust, so I'm thinking about just running a twisted pair for communications and using the PC's actual serial port. But I'm open to options/opinions. Should I go for modbus? spi? i2c? I don't really know what would be appropriate/easiest as I don't have a full understanding of all of those options.

My cable run will be about 10-12 feet, and it will be in a flex chain or similar. Which is why I'm suggesting not-usb. Plus there's a lot to be said for connectors that have screw terminals.

Your feedback would be appreciated. Apologies if this belongs more in something like the driver/board section of the forum.

Alright, Thanks for the direction Andy.

I went off and customized myself a version of Seb Kuzminsky's linuxcnc-hal-teensy project to fit my hardware and have it in it's first incarnations of running end to end. It would be really easy if you wanted to keep things fairly stock and didn't have all the usb serial port shenanigans I came across when testing on my linux machine. Everything was perfect on my windows test bed for the arduino software...

Now it's just down to finding panel mount connectors and the like to find and plumb all the electrons around to relays and such.

I am curious about userspace components. Made/modified one, works good, no complaints. But what exactly are the limitations around it? Where can I find the actual rate at which the userspace componenent's main loop is run? I don't see much in the documentation other than the statements about not expecting realtime or even maybe large milliseconds/seconds delay, but what controls that? Is it configurable? Does it only get executed when there is spare time in one of the loops? Everything else about linuxcnc timing and speeds seems so well documented, but I haven't found anything on this yet. Can anyone point me in the right direction?

Have a look at this thread.

forum.linuxcnc.org/24-hal-components/287...ver-ethernet?start=0

I did a test a long time ago doing what you want. I first used USB but later did it with Ethernet to try and get a better response from the system. Look at the thread and see a lot of discussion and tests that people did to try and get a workable system.

Thanks guys,

I've spent a few more hours implementing the actual electronics side of this project. That is the re-wiring of various relays and the like to be driven off the arduino and in the process I came across a solenoid or two that weren't equipped with flyback diodes. The previous control setup didn't seem to care, but after the changes the solenoid turnoff spike was taking my Teensy offline. I could see it remove and re-add in udevadm monitor. Interestingly usb cable length and run direction mattered. Maybe that's not interesting, but I'm not particularly good with electronics so it wasn't quite what I expected. I thought this would be a down the wire type of effect, not an RF or whatever thing. Maybe usb cables with shielding and ferrites and whatever else might be way to go in future as well.

In all that excitement I had to add some error handling to my userspace component, as I can't have the serial comms just dying and not coming back. This is really where i started initially when I didn't realize my occasional comms loss was noise related and I wasted a few hours looking for system software abusing my serial port periodically for some reason. No such software found...

So now I've got a fairly sane electrical setup, and some software that is instrumented with pins to tell me that everything is cool, or the sky is falling, or whatever. The question now is. What do I tie these to? I'm inclined to tie them to spindle-at-speed, though perhaps that's a terrible idea. I'd be missing things like coolant, or vfd control in these error scenarios, so I don't see any real reason to limit machine motion, except for motion that depends on spindle at speed, such as G1. Though some way to pop a message up or something like machine off might, may be useful as well.

Can anyone advise as to where, if anywhere, userspace component output (python prints for example) is sent when the component is loaded as part of the .hal files, as opposed to from the command line (where I can see the output on the command line...).

Also, I don't think I've seen it in any of the standard setups, but for the hyvfd I think people should be encouraged to net hyvfd.comm-ok to something useful. When things were borked with my serial ports and a program started I got some pretty scary results, including the vfd reporting spindle at speed, with the correct rpm (as the rpm was the same as last requested when it was running?),despite the spindle not rotating, and after correcting the situation by massaging some stuff the spindle came to life even though the machine was not in the machine on mode. I'm not sure if hyvfd.comm-ok will resolve all issues, but it'd probably be good to mention if anyone is giving out hyvfd advice, or modify any existing docs/tutorials.

I do believe that you are experiencing the effect that the delays in user space components can give you. If you read the discussion on the link that I provided further up you will see that there are two main problems with doing this kind of thing.

1: The USB is very sensitive to voltage conditions and the controller will switch off as soon as the conditions are not suited. In order to get the comms link up again you have to physically unplug the USB cable and reconnect. This is not safe at all. That is why I tried the Ethernet route.
2: The time given per cycle to process a full message is not enough so the message is decoded over several servo cycle periods. Over and above that there is also the OS scheduling delay that can cause your message to be several seconds behind what is really happening in the linuxcnc servo loop.

My advice is that one can use this kind of application for absolutely NON critical signals. I could not find anything that I wanted to connect to a unpredictable link.
Maybe turn the lights out when you are done?

The USB situation I'm sure depends a lot on your device/software/computer/etc as to whether it restarts or not. This might be a compelling reason to abandon USB in favour of a real serial connection, 115200baud is still enough for any sort of utility work, and is probably electrically much more stable than USB in a machinery environment.

I think you were trying to do things like coolant nozzles, work lights, etc there would be no problem at all speed wise. For things like encoders, responsive UI elements, any sort of motion control it is not useful.

That's not necessarily a deal breaker though, userspace components are meant to be easy and quick, or at least I assume that's why userspace comps exists. All this same stuff is accomplishable in a C realtime component, at least if you throw out usb and run your devices via serial or some other option. I suppose you could blast a bunch of parallel pins at an arduino and get your communications that way as well. Hard to expect the reliability and ease of a Mesa card from a 20$ Arduino.

Why don't you give the Ethernet version a bash. It is a lot quicker and more robust. It still has the delay issues but less noticeable than that of the USB.