LabVIEW
Running a LabVIEW executable on UDOO x86 ii
Hi Ahmad,
@ahmadibra77 wrote:
Do you mean I have to check how much RAM, CPU power my labVIEW programme/executable takes?
Well, it really helps to estimate which hardware is needed/required…
- What do you want to achieve with your software?
- Which tasks do you want to take care of?
- Is it about "just sending some messages from A to B" or "number-crunching on very large datasets"?
Hi Ahmad,
@ahmadibra77 wrote:
actually my LabVIEW programme controls and monitors a … rig. Open/closes solenoid valves, sets flow rate measurements, monitors pressure and temperature, etc.
How do you interface those hardware? Which DAQ hardware do you want to use?
(There are also cheap/affordable "traditional" Windows computers, search for "NUC"…)
@ahmadibra77 wrote:
actually my LabVIEW programme controls and monitors a hydrogen rig.
Is there any "safety critical" part involved?
Then you should use a cRIO or a PLC, together with some hardware suitable for safety-related tasks!
@ahmadibra77 wrote:
For DAQ, we use LabJACK boards configured within the rig. Others use RS232 serial communication.
There are safety features embedded in the LabVIEW program, including alarms and interlocks for safety purposes.
Depending on what safety we are talking about here, a software solution is not an option, or not a safe option. If there is any chance that your setup can endanger people's life or even health if it does not operate properly, software safety is simply not adequate. Your Windows system can decide to go into guru meditation at any point for any of a million reasons. It may return from that guru meditation after a second, a minute or even only after a full power cycle. If your system relies on the software detecting dangerous situations and consequently shutting it down or going into a safe mode, you have a real problem.
If the consequence of a software failure is only material, it can be acceptable but still needs to be assessed. If your expensive experiment gets ruined by a failing operation, that can be rather unpleasant but sometimes you have to accept a certain financial risk. However a bit of hardware, even if you go with dedicated safety relays or a cRIO is usually already cheaper than a failed experiment or damaged setup. Saving in this aspect is almost always turning out to be more expensive in the longer run.
You think a cRIO would be suitable? I was also looking at LattePanda which is also very compatible with LabVIEW.
cRIO is always an option unless you need true hard safety, but it's price is in an entirely different league than your SBC! 😀
cRIO is realtime and can guarantee a certain response time but only if the program you deploy onto it is programmed correctly. Guaranteed response time helps nothing if your software program then borks up things. Also if your cRIO looses power or is damaged in some way and you have no additional safety net in the form of true hardware interlocks and protection, you can have a big problem anyways.
And for regulated industries like nuclear or similar, you won't get away with uncertified hardware and software at all, no matter how safe you claim you made it.
Hi Ahmad,
@ahmadibra77 wrote:
My objective is to power the rig using an SBC that is comptaible with LABVIEW, and then interface with it remotely from another computer. That’s the purpose of integrating the SBC into the unit.
You seem to provide information only piece-wise by adding bits from time to time…
Does the SBC run headless?
@ahmadibra77 wrote:
Hi GerdW,
apologies, but I did try to capture the full scope of what I am trying to do. Overall, I would like to run a SBC computer, potentially connected to monitor (not headless) which I can interface with remotely and run labview executable programme from the client computer. Currently, I am able to run my hardware (i.e. the rig) using LabVIEW programme connected via USB over labjack devices and rs232. The objective is to utilise this SBC to be able to integrate it to the rig, whereby a client computer can access it through remote connectivity. By using SBC, I thought it could be straightforward, as the only thing which theoretically has to be in place is that the SBC has to run on windows x86.
I hope this explains what I am trying to do overall. Please if you have any questions let me know.
RS232 communication can still mean you get kHz's of data, and if you want to FFT that and feed it to AI, a SBC won't cut it.
But it sounds like you have <10 Hz of data and want to do some simple control and maybe some logging, some alarming maybe.
It's still a guess, but it sounds like your requirements are pretty low.
If the exe runs on a normal PC with a few % cpu, you should be fine.
Next question is if you really want Windows on it.
Windows is often forced to be under the IT department. Even without IT, Windows will force updates at it's own (random) schedule.
Windows IoT is an option. Linux too.
Search LabVIEW like a graph!
@ahmadibra77 wrote:
I’m not entirely sure what you mean by “safety” in this context. All safety precautions for the project, risk assessments, HAZOP studies, COMAH requirements, etc. have already been addressed. My question is specifically about safety from a software or system architecture perspective. For that, I am not familiar of what can actually go wrong with the software and maybe you can educate me on that?
You mentioned safety and neither was I sure what you meant with safety! People on here regularly come here to ask about safety in connection with LabVIEW programs, and quite often they mean safety in terms of harm to people and/or serious hazards, and they all have to learn that software alone is NEVER EVER an adequate means to guarantee such safety.
You mention software or system architecture as a concern and mention that you are not familiar what can go wrong in that aspect. I would say that Murphy's law is fully applicable here and really anything that can go wrong will at some point go wrong! Your software can do all kind of bad things and the only one that can asses it is the programmer or a VERY thorough reviewer of the software. Your application can for instance simply get stuck waiting on some message from a device that was disconnected for some reason and then stop polling any safety relevant variables and taking action on them. Basically software and system architecture and design is a very complex topic and there are more things that can go wrong than you can imagine. Even experienced programmers can and will discover serious problems during development that they would have sworn to never ever cause.
My objective is to power the rig using an SBC that is comptaible with LABVIEW, and then interface with it remotely from another computer. That’s the purpose of integrating the SBC into the unit. If you’re suggesting that the SBC could shut down unexpectedly or fail, that risk is understood; any computer can fail. In such a case, the rig would automatically shut down, and the existing safety systems would prevent a hazardous situation.
Could you clarify what additional safety considerations you believe arise specifically from using an SBC?
If your hardware itself has intrinsic safety, and can in addition for instance detect that the PC is not responding properly anymore, for instance through the use of a watchdog or similar, you are possibly safe. I say possibly since you could create an application that keeps petting the watchdog in an independent loop while the main control loop controlling the entire experiment got stuck in some huge timeout or logical lock. And the only person able to prevent such situations is the programmer, so quite likely you in this case.
