Easy expansion of I/O using Modbus

[Richards]

I've been following the threads where more I/O is needed for tool changing. I'd like to suggest that in the next software update that Modbus protocol be added. Modbus protocol is already available for the Beaglebone boards. It is also available for the Arduino and for Raspberry Pi.

The concept is simple. One device acts as the Client/Master. It reads or writes data to other devices that act as Server/Slaves. With the Acorn acting as a Server/Slave, the Acorn would only have to load four registers each time a tool change was needed. One register would contain the number of the current tool. Another register would contain the number of the desired tool. One register would be set to '1' to command a tool change and the fourth register would be preset to '0' as the completion status register. A Client/Master (Arduino, Beaglebone, Raspberry Pi, or PLC) would query the Acorn several times per second. When it read the register inside the Acorn that a tool change was being requested, it would grab the data for the current tool and for the desired tool. It would reset the command start register to '0' and when it had finished changing tools, it would set the finished register to '1'.

Modbus has been around since 1979. It is used in factories throughout the world to allow machinery to communicate easily. It allows the programming team to off-load tasks to dedicated PLCs or other computerized equipment. Right now, I use three AutomationDirect P-1000 PLCs and three AutomationDirect CLICK PLCs as test machines to validate logic on the RX3i GE PLCs used in the field at oil refineries. At the oil refineries, the PLC doesn't need to know how a valve or VFD works, it only has to know the IP or RTU address of the device and the registers used by the device.

There's no doubt that the I/O expansion board that's being tested will solve most of the problems that tool changers require, but, just like everything else, as soon as there's a way to add 75 I/O points to a system, somebody will need 76 I/O points. Modbus was developed so that virtually unlimited expansion could happen.

When I first tested Modbus with a CLICK PLC and an Arduino Uno, all I had to buy was a $2 RS-485 board for the Arduino. Everything else was open-source software. Because the Acorn already uses Ethernet, Modbus TCP could be used that wouldn't require any modifications to the Acorn board. Everything would be done in software. With the Acorn acting as a Server/Slave, there would be almost zero overhead, meaning that timing routines should not be affected. If necessary, a single Acorn output could be used to signal the Modbus Client/Master when it was safe to perform Modbus communication.

[martyscncgarage]

Mike,
No need for Modbus
Ether1616 will handle it. Coming soon.......

Marty

[eng199]

Modbus protocol is already available for the Beaglebone boards.

Are you talking about Linux drivers? ACORN doesn't use Linux.

as soon as there's a way to add 75 I/O points to a system, somebody will need 76 I/O points.

Centroid has run large, complex mills and lathes worth $100k+ on less I/O than this. I suspect that poor planning is involved if 50+ I/O are needed and the choice of control is a $299 ACORN. The cost/effort/complexity of just wiring mass quantities of discrete I/O is a good reason to simplify or multiplex connections.

The Ethernet expansion board will be available soon. Sorry it is not what you wanted.
Testing a multitude of other vendor's Modbus TCP products and getting the wizard working with them probably would have stretched the release date even further.

[martyscncgarage]

Richards,
If PLC's Modbus are your thing, that's great. It has applications.
OAK and ALL in ONE DC have powerful well engineered PLC's built in them as does Acorn. Acorn's issue is that it didn't have enough IO
With Ether1616, it will have that capability....

Centroid KNOWS CNC Machine motion control. They've been doing it for over 30 years.
At ACORN's price point, a lot of people are asking a lot out of it....when they should move up. But even so, Centroid is trying to provide a solution. Hat's off to them for their efforts.

[Richards]

It looks like I've upset some people. I'm not debating the value of the Acorn. It is an excellent product that is worth much more than the selling price. I'm talking about making machines work the way that the user wants them to work. If a user needs to add a tool changer to his machine, how much should it cost for the extra computer hardware? An Arduino costs less than $5 on eBay. I've used hundreds of them in various projects with 100% success. For people who might not like to program in C++, then a low-cost PLC for $150 will do everything necessary.

Let's consider the I/O required for a 9-position tool changer. Four outputs to specify the tool number if using binary (16 tools possible). One output to signal the tool changer that a tool change is required. One input to detect when the tool change is complete. That requires six I/O lines for a very simple addition to the CNC machine. (Five I/O if eight or few tools are used.)

With Modbus, NO I/O is required. Everything is handled in software. When modbus protocol is available on that $5 Arduino and is available on all of my BeagleBone devices, there is no extra licensing or hardware costs to use modbus. There would be programming costs to incorporate it into a product.

I'm looking forward for the new digital board. I plan on buying one and using Wireshark to see how it works. In the meantime, I'm using a lot of PLCs all interconnected with Modbus to do much more than they were ever designed to do. On the jobs that I consult, a $20,000 G.E. PLC conect to dozens of remote devices allowing that single PLC to run refineries that cost more than $1,000,000,000 to build.

No offense was meant. If we never look at options, we'll never know what possibilities exist.

[martyscncgarage]

Understand. Eng199 is THE Engineer at Centroid. No harm in asking. Given your experience with PLCs and controls, I can see why you would request it. Centroid has other plans all good and worth waiting for.....

[DannyB]

So it seems centroid is going with ethercat over time, which is a much better idea. Having done a lot of modbus, Ethernet/ip, and ethercat, im glad. Modbus actually has a tremendous number of compatibility and other issues (it should not be used for anything safety critical, etc) that ethercat simply doesn't.

Modbus has its place, but it is mostly useful for interacting with vfds and such that are taking care of logic on their own and where having no guaranteed response time or safety around multiple clients or ability to handle large number of I/o is okay.

Modbus has no guarantees around a *lot* of things, and what you get trying to interact between anything is a mess.

[Richards]

Let's return to the original premise: A tool changer. What are its requirement? It has to know which tool is in position. It has to know which tool is needed. It has to know when to change tools. It has to send a signal when the change has finished. Speed requirements are minimal. Physically moving a turret might take several seconds. Using traditional I/0 requires at least five I/0 lines for 5 to 8 tools, six I/0 lines for up to 16 tools. Speed is not a primary concern. Moving the turret will take one or more seconds, meaning that data updates every 50 millisecond is reasonable. Price might be a consideration, but being able to use an Arduino, a Raspberry Pi, a BeagleBone, or a PLC as the brain of the tool changer keeps the price for the computer portion a less than $200 with a PLC and less than $75 for the microcontrollers.

On a CNC router, there are other "options" that require I/O, such as zoned vacuum systems, material handling, sheet placement, to name just three. Each of those "options" require I/O. A six-zone vacuum system needs at least three bits. Material handling would need six or more bits. Sheet placement needs at least four bits. Add to that advanced limit sensing, with two-sensors per axis, safety monitoring to assure that all guards are in place and functioning and the bit count continues to climb.

The Acorn is perfectly capable of handling machine axis movement. It can handle many of the customary requirements of a CNC router. With the new I/O board, it could handle many more options. BUT, at some point even a controller as functional as the Acorn will run out of horse power. Memory is finite. CPU cycles are finite. Expectations must be kept within the limits of the hardware.

Now, if everything associated with the "options" were off-loaded to other intelligent devices and if communication between the Acorn and were handled via a port or ports on the existing Ethernet connection, then a $300 Acorn becomes a $10,000 controller at a fraction of the $10,000 value.

DannyB addressed the issue of safety. That is always a concern. That is also why protocols carefully spell out how to use components in the system. In a Master/Slave system (commonly referred to as a Client/Server system when using Modbus TCP/IP), the protocol calls for having only one Client. That keeps multiple clients (masters) from asserting control over the servers (slaves). The client coordinates all messages. At that point, the programmer is responsible for assuring that each device has all the safety features enabled and properly operating.

EtherCAT is one method to enhance the Acorn. EtherCAT is an excellent choice, but it is only one of many possible choices. It is a Master/Slave system. If the Acorn is the Master, then memory and CPU cycles are still limitations. If the Acorn is a slave and if all of the optional equipment added are slaves, then a Master must be installed. If an external Master is used, the cost might become a factor, especially when compared to the price of low-cost PLCs commonly used in industrial environments.

EtherCAT allows the coordination of multiple axes, more than the Acorn now handles. But, at what cost? At what point does an Acorn with EtherCAT and EtherCAT compatible motors cost more than other Centroidcnc products?

When I was a boy, living on a farm in a very small town in eastern Utah, there was a saying used when farmers talked about the new farm equipment they'd seen at the dealer. Knowing that most farmers in my area had small Ford or Massey-Ferguson tractors, the older farmers would caution the dreamers that they were putting a $1,500 saddle on a $50 horse.

[DannyB]

Hey Richard,
Just gonna flag for you that the way you talk about a bunch of this stuff comes off as a little condescending . I appreciate that tech levels vary, and you are talking to a new audience, but you seem to be assuming that a lot of us don't know how these things work.

A lot of us are quite familiar with the underlying ways these technologies work (and some of us helped build it - my background is in chips and compilers - the compilers/debuggers used for most of the boards you cite are things i worked on for 20 years ).

While I have no disagreement that modbus is cheaper, i'll reiterate that in practice, it is a mess for users to try to use with multiple products, and is hard to make safe for more than the reasons you mention. I can go into great detail in this. Any two pieces of modbus hardware will have slightly different numbering. Or the data bytes will be in a different order (despite what is required). Or ...
You only have two data types, boolean and 16 bit integer. This makes it literally unusable for a large number of things, so people hack around it by trying to use multiple registers to represent a larger value, and all devices do this in a different way.
In fact, some devices try to insert new data types!
The number of spec violations in real products is insane (from data to timing to CRC in some cases!).
It's actually what drove ethernet/ip and ethercat to have real conformance testing.
There are literally no standards for how devices are laid out and used, requiring custom handling for every single vfd/etc (compare to ODVA standards for vfds, followed by almost all VFD's, for ethernet/ip, or CIA-402, used for CAN and Ethercat). That makes it really hard for someone like centroid to play integrator.

Meanwhile, I have about 30 lines of PLC code that handles driving any CIA-402 device, and had about the same driving ODVA drive profile compliant devices.

The modbus protocol itself has no safe state machine like you find in other protocols, ensuring that when the devices are in a bad state or starting up, bad data is not given, and giving you the ability to monitor the state of the device network.

Additionally, relying on clients not simultaneously contacting it is broken, in practice. Even a single device might try multiple "sessions" if it thinks the last one timed out due to modbus's weak error handling. I have *actually* watched this cause serious issues.

There are very good reasons you don't see it used much industrially for anything critical, only in very low cost situations.

As for ethercat CPU and memory usage, this is ... mostly a red herring. The machines used with ethercat are often *very* low power ARM devices.
Much older and slower than what is on the beagle.
There is also a a very cheap ASIC if anyone cares to reduce usage to zero.

There are also plenty of master software for windows 10, and on a machine that meets acorn's bare minimum requirements, the twincat master (as an example) takes <1% cpu running a PLC program, and is isolated, so it will not interfere with user space.

(I can show you graphs)

All told, again, I think modbus has its place, but a CNC machine is not one of them. That isn't to say users don't do it, but it is a bad plan. Its best use case is in HMI. Past that, it's time has long past. Literally *any* protocol (profinet, CAN, ethernet/ip, ethercat, etc) is a better choice.

Most higher end CNC machines (biesse, etc) and mills use ethercat, and it seriously reduces the number of wires/does not need separate configuration (IE every ethernet/ip or modbus tcp device must be config'd separately) which is why i expect Centroid went with it for Hickory.

But even the click PLC's support ethernet/ip these days.

Even if someone was worried about ethercat cost/usability for some reason, i'd still use ethernet/ip over modbus every single time.

[cbb1962]

The number of spec violations in real products is insane...

Several years ago I was dealing with legacy components that used RS232 cabling for connectivity. The Lead Engineer at my company had a pet peeve about "RS232." He would say: the RS stands for "Recommended Standard." Then he would laugh and say; "Is it a Recommendation or is it a Standard? But instead, manufacturers treat it like a suggestion. Check the specs on how RS232 is implemented on every device, every time."

His advice reminds me of your experience with ModBus.