Very complicated labview block diagram

[altenbach]

I agree that the code does not look too bad and is well organized. Why is there a big breakpoint?

You have dozens of loops running in parallel and many of the small loops could probably combined becaue they run at the same rate.

Code itself is a bit heavy handed, with many stacked sequences and local variables. Does it run well? Are there known bugs or race conditions? Does it run fast enough or is there stalling? How is the overall CPU usage? How old is it?

[paalbrok]

I think it runs quite OK, but sometimes they have errors with the program that they can't explain, probably because of race conditions. I started 2 weeks ago in this company and just had the program handed over, so I don't know all the details. It is running fast enough, but I know they use a quite powerful computer to run it. I think it's a bad idea to run all the code locally on the computer. They use Phoenix Contact modules for I/O (not PLC). The computer communicates with the I/O's over ethernet. It should for sure have been a real time system, where the resources are divided between a host computer and a target like a compactRIO to achieve determinism and stability and reduce PC CPU usage. I'm thinking of transfer it to some kind of real-time target, but we have to keep the expenses low. I'm thinking of maybe the new Single Board RIO or even Arduino(!) if it would work. Any suggestions?  

[WNM]

There are some relatively inexpensive cRIOs available that integrate the RT controller, FPGA and a small backplane into a single device. The cRIO-9075 is an example of one that I have used several times.  The cRIO route may cost a little bit more than the single-board RIO but you can save some money on the other end by not having to come up with packaging for a bare board.  The cRIO can also take advantage of the wide variety of fairly rugged I/O modules available for that system.

[BowenM]

---

@paalbrok wrote:

It should for sure have been a real time system, where the resources are divided between a host computer and a target like a compactRIO to achieve determinism and stability and reduce PC CPU usage.

---

I'm actually going to disagree with you there.  When you are talking brake dynos, you really don't need that tight of control loops.  Your brake pressure servo valve is likely the fastest and most of those are on a 20 Hz time scale. Aside from that you have some dyno velocity, maybe some motor control though that is likely done offline in a PLC.  Acquiring your return data (torque, etc) doesn't need to be real time at all.

Just my opinion. There is a company here we have worked with that specializes in brake / auto testing and all of their programs are run on host-pc.  It drops the cost, lowers the program complexity, and RT isn't really needed for slower mechanical systems.  TCP/IP is fast as long as you aren't streaming across a large network.

[paalbrok]

Thank you for your opinion.