Production line Project design pattern

[Łukasz]

Hi, i'am looking for knowladge about project design pattern for control application with more then 1 cRIO controller. My task is to choose architecture, so i like to know which communication way is common use, which designe patterns are good to build main VIs, general good practice etc.

The project is a production line with lots of servos, CVS controler with vision algorithm, and desktop application as a SCADA system. 

At this point, i think is good to use Simple Messaging Library to send communication in system and Current Value Table to sending data. Also i will use "standard" Queued State Machine Design Pattern on each device. 

I will be gratefull for any source of knowladge about how to program similar systems.

 

Best wishes,

Lukas

[smithd]

If this is as large as your post makes it sound, this is not an question for an internet forum. It sounds like you need assistance from an alliance partner or NI sales support group. Your field rep can get you in contact, or you can find alliance partners on ni.com/alliance.

As a starting point, I'd suggest skimming this: https://www.ni.com/compactriodevguide/ .

Edited February 13, 2017 by smithd

[Łukasz]

Thank you for your response,

i already had read Compact Rio Dev Guide and also we will contact NI support. I just want to be well prepared before project starts. I like to collect any tip, which could be usefull at planning state. 

[smithd]

Fair enough. Again the field is too broad to answer generally, but I can share two varieties I've worked on, both in the general area of SCADA.

Project A is more of a local control application, where there was a decent amount of logic on the distributed systems. www.ni.com/dcaf is a good example of the general design used -- all data goes into a central storage and the control loop operates continuously off of that storage without ever stopping. Events were implemented as tag changes. Data is transferred between device and HMI by copying the full tag table between systems, so there is no concern about missing an event. This could be implemented using the CVT client comm library if you're using the CVT, but in concept its very simple -- make a TCP or UDP socket, send data on that socket at a fixed periodic rate.

Project B was more of a daq application with a lot of attached devices and instruments and a tiny, tiny amount of control. As such, an event-oriented approach made sense. Everything used a QMH, data went over the network as separate packets in a TCP stream and were processed as individual updates (although for some HMIs this was copied into a global tag table like the CVT). Here, a TCP stream was used for data updates, while messages were sent using a request-response protocol on top of TCP (think similar to http). The advantage to this is that you always get a response immediately. If you say "move to here" and it knows it can't, you'll find out immediately rather than having to (for example) look for a fault bit to be set.

For every system I've worked on I've found syslog to be handy -- this could be either the UDP-based library provided by NI or just making a simple string file logger yourself. Debugging is always a challenge, so a standard way to report human-readable information (debug messages, status updates, errors) is critical. If you make your own, timestamping is important.

Some people like to have a central error handler, but I've never seen this work well. Reporting, sure, handling, not as much. My general pattern is 1-check for expected errors, 2-if the error is not expected, reset the process from scratch and report. For example if you're talking to a serial instrument and you get an error, tell anyone who might care, close the visa session, reset, and try again. Don't try anything fancy to fix it.

[drjdpowell]

There are multiple ways to do things; but pick one.   Be wary of mixing different methods in such a way that the result is overly complex.  So when you mention mixing CVT with an independent messaging system, that’s a worry.   Note that smithd’s Projects don’t mix the two.

Personally, I follow the messaging paradigm, rather than CVT-like tags (my tag-like functionality is a Register-Subscribe notification system build on messages), and I have a standard library and template for QMH “actors” (note: NOT Actor Framework) that can communicate locally or over TCP/IP (some videos).

[ShaunR]

No requirements specification; no solution.

If you don't have one, then write one. It will force you to consider the details of the system, the components and how they will interact. If you are in the position to dictate component/device choices then choose a multi-drop interface and ensure all devices/components use that interface (TCPIP/RS485/Profibus whatever-find the common denominator). Then try and normalise the protocols (SCPI for example). A judicious choice of device interface options  means the difference between juggling RS232, TCPIP, GPIB, RS485 et. al when they all may have TCPIP options when purchased. It will decrease the code complexity by orders of magnitude when you come to write it.

Once you have all that defined and documented, then you can start thinking about software.

Edited February 15, 2017 by ShaunR