You’re given the task of planning a new project. Everything's on hold until you have a costed plan. The project must be linked to the internet, is not a consumer product, and the volumes are possibly in the hundreds, but even that may be wishful thinking. At these numbers the buy- build is a no brainer. You are initially drawn to the tangible costs of hardware. Obviously avoiding special tooling, anything involving machining, welding, injection molding you scour the internet for off the shelf components and modules, hunting for somewhere between too much to integrate and too high a level of integration. Next you look a timeline, how many hard to find staff will it take? Will you need new hires; you know the labor costs have sky rocketed. You have a much smaller team in house than you would like. You chart the timeline based on your experience. It’s too long with your current staff, and you know with the projected costs it will not get approved! Fudging lower costs will probably backfire during the review.
But where’ are the major costs? Software, it’s always software. The buy-build conundrum is always inherently about hardware. But is it? Open source software libraries have been around for years, so have drag and drop graphic apps, but move down to non PC type apps, and things start to look more like a highway with roadworks; very patchy, hard to navigate, nasty surprises, and hard to determine a time of arrival. You opt for PLCs, they seem expensive, but you can always ‘build’ if the volumes pick up. The project has some motion control aspects, now you know you’re getting into costlier territory. Prices of motion controllers are so high for so little. Even so you know it’s still the software that is going to blow the costs and timeline.
That is the problem that the Blue Button set out to resolve. WiFi, Ethernet were givens, but offer a choice of short range or wiring. In a monitor / control environment, where most of the traffic is very small packets, Inter/Intra net is very slow because of connection times. RS485 can be 100 or even 1000 times faster, there is wiring but it’s simple. If the packets are small even LoRa can be very effective. Chameleon NetPLC's have them all in one module. Our library uses 3 simple functions to access all the different common I/O (digital I/O, ADC, DAC etc) even adding things like contact debounce for buttons etc.
Our first #include library for our Chameleon NetPLC controllers (chameleon) resolved most of the myriad of syntax differences by combining access to any of the controller's or extender's I/O. Our NetPLCs have a proprietary routing mechanism for SPI and I2C so we can have as many of the same type of chip with the same I2C address, and as many SPI chip selects as we want – no jumpers no complex programming, it’s all done by the 3 functions transparently.
Our system is powerful; it can be networked any way you want,- transparently just using node and pin names. Our network messaging layer ChamNet, running in the 2nd core that makes every pin on every intelligent node look like a C++ software object; I/Os become properties. You can toggle any digital I/O, set a motor speed or target position with a simple call to the write function with a name and a value. You can even do it from anywhere in the network if you wish.
Imagine a factory floor with work cells, each with a few PLCs; that could add up to 1000 I/O of various forms. How do you manage all the configurations and updates? Yeah, that’s what we thought, it’s becoming a monster. It took us some time, but after many rabbit trails, we came up with the ChamNet configuration tool. Nodes and I/O names (properties) and methods are all defined in the spread sheet. All routing information and initialization is also defined in the spreadsheet, providing a semi graphical representation of just a simple one module machine or many work cells on the factory floor.
Our naming convention is like a file system, but it is intelligent. It has a relational database inside, and as far as property (I/O pins) are unique in the system, you can access an I/O pin across the world with a simple call to the read / write property function using just property name and value, whether it’s an ADC input, or DAC or solenoid driver output. Can’t remember a name; just check the configuration tool that’s as comparably complex as a map of the London tube system (but not as fascinating). If the I/O name is not unique (because you copy and pasted work cells), then you precede the I/O name with as much of the node path as necessary.
Sounds great, but how do you manage such a variant network of nodes, subnodes and I/O pins. Well we aren’t CISCO so we compromised; we used a spreadsheet to define groupings of nodes and subnodes and I/O for a whole enterprise system somewhat graphically, and were also able to include all the routing and even the initialization of every single I/O pin in the whole system. You simply save it to an SD and insert it into the SD socket on every controller node/subnode in the system (yes the same file). Soon we’ll be doing that over the network.
We have based our NetPLCs on the Arduino IDE and our ChamNet messaging layer making it even easier than an RTOS because ChamNet's Event Messaging. This totally obviates polling, linking received Event Messages to processing code. Properties, Methods and linked functions to Events, what could be simpler.
Unified I/O access code functions, hardware that looks like properties and methods, and changing initialization without reprogramming the PLC, now that would save you software development time, not to mention lifetime maintenance costs? So it’s not the hardware costs and now it doesn’t have to be about the software costs, it’s about choosing the right PLCs.