LinuxCNC as a ModBus HMI

Hi

I've been looking for a Linux based project that I can use reliably for building machine HMI, and struggling to find anything either still actively developed or that isn't a proof of concept school project.

I'm using LinuxCNC for CNC machines, so makes sense to use the same platform for "simpler" machines.

So first things first, a quick definition - by HMI, I mean just an HMI - not a PLC, but something that graphically displays a process or menus to interact with a PLC (or maybe another LinuxCNC system, but via a bus). I'm not looking for a PLC; they're plentiful, reliable and cheap these days. It's the HMI that are a struggle to find. They're normally cheap Chinese, and likely to be poorly coded, web browser based (with the client code in Java) or super expensive solutions (Siemens, Schneider, B&R) that are normally embedded Windows CE. The only place for "PLC" logic on an HMI is just to create logic for the interface and user interaction itself (i.e. enable button X in mode X, but disable buttons A, B, C etc) but that's probably better being inside the UI Python code anyway. An HMI's code should be non-essential to a machines safe running!

To clarify, with an HMI it doesn't need to be "realtime" as you'd require for controlling steppers/servos, it needs to be fast, but if you compare what's on the market, they're all low-spec embedded SOC devices or its server/client web based tech, so even a non-realtime solution would outperform this stuff. Anything that's realtime shouldn't be near an HMI - they're just to show an operator what's happening and enable them to control the machine in some way. E-stops and safety functions have to go through safety relays or safety PLCs, and never via HMI too!

So, what is the most stripped back configuration of LinuxCNC? Will it work with me removing everything excluding ClassicLadder (for Modbus and basic UI logic) and PyGTK? I'd even like to try it on small embedded touchscreens, which normally have be specs of an RPI, so the less that's loaded the better.

What's the very minimum needed in a config file to get the UI running, ClassicLadder and the ability to map pins to the UI?

Thanks
Jon

Hi Andy,

No that's close...

All I need is enough to have a tiny/simple UI running and ClassicLadder with modbus.

However, reading into ClassicLadder, is it really the case that without the CL UI running, that modbus doesn't work?

J

bymccoy wrote:

Hi Andy,

No that's close...

All I need is enough to have a tiny/simple UI running and ClassicLadder with modbus.

However, reading into ClassicLadder, is it really the case that without the CL UI running, that modbus doesn't work?

J

I think it might be true. I only ever experimented a little with Modbus in Classicladder. (Just enough to see it would not suit my needs.)

Perhaps using Mb2hal would be a better option for you? You might even be able to do all your logic in Hal and not use CL at all.

It is possible to hide Classicladder's GUI while using modbus - there is a HAL pin to do it.

Chris M

Thanks guys...

From the sounds of it, MB2HAL will be a better option, although, maybe a dumb question, but where/how can I create I/O logic (the stuff that doesn't belong in the view/UI layer) other than AND/OR etc, or do I need to build a custom HAL component for that? My reasoning behind using CL was so that I could have logic as well as the ModBus interface. However, from the sounds of it, even though I can hide the UI for CL, it's not quite an 'embedded' experience, whereas I can create an end-to-end experience using a custom GUI and MB2HAL.

I feel like I've been asking some really dumb questions about use/setup/architecture - but I've struggled to understand the architecture/config of LinuxCNC, purely as I haven't seen/found any structural flow charts (if they exist) showing how it all fits together. It's a combination of lack of time at present to experiment and maybe not finding the right style of documentation that clicks with me (I've worked on lots of very large and scary platforms and code stacks so not adverse to figuring stuff out the hard way).

From what I understand, the core of LinuxCNC is a realtime scheduler, and enables 'wiring' of virtual IO. Functionality that actually drives something is achieved through HAL components (that are also scheduled according to need), ie MESA IO, Motion Planning, ClassicLadder etc, so we can wire these physical/virtual interfaces...

Thanks

There are a number of hal logic components.
linuxcnc.org/docs/html/hal/components.ht...d_bitwise_components
Really, I don't think the basic concept of Hal is all that different from a ladder program.

But if programming in a ladder environment is easier for you, it is simple to use Mb2hal with Classicladder. I am doing this on a machine. I was not able to use the Modbus part of CL in my application because. the number of separate blocks of registers I needed to read or write to exceeded the limit of 16 that CL can do. (I needed 32 total, 4, for each of 8 VFDs on a gang router.)

Thanks Todd!

Using boht MB2HAL and CL seems a good idea - I get more I/O plus it's seamless (ie no gui or hacks to hide CL gui), but if need to program in ladder then I can...

Will have a play around with that I think then!

The limit to the number of blocks of registers CL can read or write to is not the limit of the number of registers that can be read or written. Confusing? Not really, CL can read or write to a large number of contiguous registers as a single block. So reading say 50 (an arbitrary number I just chose) registers can occupy only one of CL's 16 register read/write commands, giving you 50 input points in one fell swoop. (and Mb2hal can work similarly.) I was hamstrung by the way the VFDs I was using organized their Modbus control requiring separate reads and writes of non-contiguous registers to operate.