Products > Embedded Computing

Industrial machine user interface Controller solution

<< < (3/5) > >>

So what is the deal with Codesys ? looks like an ideal solution for turning various hardware into a HMI or have a misunderstood?

Codesys is a generic HMI and PLC / general automation software. It's a third party platform that IFM and others use (IFM have a specific variant but it's still Codesys). It can do both HMI and general ladder / function block stuff. Most of our projects were on 2.3 but the new projects are 3.5.
I don't do much of the work directly, I usually do the test rigs and commissioning. I know some of the limitations that bug me are slow upload (even over ethernet) and sloooow graphics functions, hopefully they are fixed in 3.5. But in general it's par for the course for these types of environments.

Whatever you choose be sure you have a technical contact, these sorts of systems are just as quirky as embedded, there are often errata that you have to find workarounds for. Also, when dealing with engines, expect the unexpected. ECUs in low-med volume OEM are custom programmed with certain parameters, usually incorrectly if it's a new spec, so you can spend days wondering why your CAN control isn't as you expect only to find the ECU is flashed wrong.

The other option our competitors tried was the bigger name PLCs (Siemens, Mitsubishi etc) intended for fixed plant. Don't go there, they are not rated for the vibration, ingress or automotive supply rails.

what about running a web page in a full screen browser?


--- Quote from: Simon on June 22, 2023, 08:15:51 pm ---- What maximum acceptable delay between power-on and the user interface usable?
What a silly question ;), instantaneous of course! OK, less than 1 minute, there comes a point where you have to say, look, cheap and slow or fast and fooking expensive, you choose boss/customer

--- End quote ---

Yes it is silly, which is why I asked.

Jokes aside, the power-on delay (or "boot" time if you prefer) is a key spec of any UI. Not even sure how that spec could even be missed.

As we've all been subjected to, there's been a trend in "modern" lab equipment to have pretty long boot times (scopes, sig gens, even some multimeters now...)
This can be extremely annoying.
But in some application, the delay may not be only annoying - it could be a safety concern, if you have to wait a full minute before being able to do anything.

Obviously this spec can lead to completely different solutions. If only a couple seconds or less is required, almost any Linux-based-on-a-SBC solution will be out of the question. Although with some SBCs and great care configuring the Linux boot (and not going to a full desktop environment), that can be usually lowered to a few seconds. Have never managed to get something operational with this setup in less than about 5 seconds. Whereas with a MCU-based solution, the power-on delay can be nearly instant (a few ms to a few tens of ms.)

If in your case up to 1 min is acceptable (make sure of it though, as it could again annoy the hell out of your customers, even if there is no safety or otherwise written constraint), any Linux-based SBC solution with an off-the-shelf display will work. Program the UI in your favorite language, there's no lack of them for quickly building UIs. Done. Also, if selecting this solution, ideally set it up in a read-only manner (which may take some work on the Linux config side) so there's no possibility of data corruption that could lead to a non-working state.

Not sure about the new generation of controllers but the current/legacy CR1080 that we use would have no chance of that from what I've seen. The only connectivity we do is a 3rd party satellite modem that talks over CAN and parses out the basics.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod