Understanding different data types in your PAC Control programming.

You don’t need to have the title "software engineer" on your business card before you code up your first automation process. In fact, I suspect that many industrial automation folks are like me—self-taught and come from the school of hard knocks.

This blog post is more of a musing out loud than a "you must" edict. Programming, after all, is often more art than science.

I hope you got a chance to read my last blog about Add delays to speed up. This blog expands on that and my mention there of the Deepsea Challenger submarine. Specifically, I’d like to break down a single sentence that I alluded to in my Part 2 blog on Deepsea: “Ensuring the software never waited longer than the usual healthy time for a response helped as well.”

The submarine had around 180 devices that were a mix of both read-only and read-write serial Modbus registers. In addition to the mix of register densities per device, there was also a mix of baud rates. On top of that combination, the sub was split into 5 zones for resilience. Port and starboard were split (left/right), and each side was split into three parts (top, middle, bottom).

The Opto 22 PAC Control strategy had to constantly adjust timing loops to ensure that the pilot did not notice any change in the overall response of his joystick controls at any point in the dive, especially if one or more devices succumbed to the pressure of the ocean.

Tip: if you want a bit of a fun view of Deepsea Challenger, check out the simulated screens we built on demo.groov.com. Log in with username: trial, password: opto22.

So how did we ensure that the control system constantly self-adapted to so many systems, baud rates, and possible device failures? Enter (finally!) the subject of this blog: Variables vs Literals.

In my last blog, I encouraged PAC Control programmers to put a literal ‘delayMsec(100);’ command somewhere in every path through every chart. The 100 msec value is a "loosely based-on-experience" starter value. 100 milliseconds is good for humans and many machines, but it's not the right number for every application. More so, if the process you are working on changes, as was our case with Deepsea Challenger. Hard coding a literal 100 millisecond delay anywhere would quickly lead to, "I wish I had made that a variable."

Any "fixed" number that might need to change at some point really should be a variable. Literals should only be values that you are sure will be constant and never change. 

The Deepsea Challenger submarine had 12 serial ports in total to communicate with roughly 180 serial devices. Timing this data exchange was a key part of keeping the submarine performance consistent for the pilot (and topside engineers monitoring the telemetry) during each and every dive.

In short, we used the PAC Control strategy to create a timer variable for each good serial port interaction with every serial device. This "best effort" device timer value was added to a table that we used every time we talked with any device. If it took longer to supply its data than the table variable, it was marked as "sus." Three sus counts, and that device was dropped from that serial port round-robin for the rest of that dive.

That table, full of variables, then became our benchmark—the gold standard. We knew exactly how long each device took to return its array of data at its baud rate. The charts knew how long they should wait to hear from each device. So that delay value was the bedrock foundation and the equivalent of my suggested ‘delayMsec(100);’ 

But on any dive, one or more devices might fail, taking much longer to reply to a poll for their information, or ignoring our commands to them. In this case, if we waited in a loop for them, other devices would then be forced to wait. If left to run this endless loop of "hurry up and wait," the pilot would notice the submersible becoming harder and harder to control as his joystick command would be slower and slower at successfully sending serial commands to the thrusters. We know this because it happened on one dive where we did not handle an unexpected edge case and had to adjust some values—which, thankfully, were variables rather than literals.

To this end, all the PAC Control strategies I code end up having three delay variables.
Here is a screenshot of one of them:

I call them ‘delay_short’, ‘delay_mid’ and, yup, you guessed it, ‘delay_long’.
This way, I am able to live-tune the strategy response very quickly and find the sweet spot for the process I am working on.

For any coder who has been around for any length of time, this may be an all-too-obvious blog topic. Indeed, one of my co-workers simply takes the blanket approach of “just make everything a variable,” which can have its benefits and clearly works for them. But what about the value of Pi, 3.141592? Should that also be a variable?

Like a lot of things in life, balance is the key. As I mused at the beginning, programming is a mix of art and science. You need to find what works for you. All variables for my co-worker, and a mix of variables and literals for me.

Drop us a comment if you have any thoughts on when a number should be a variable or literal. 

Till next time.

Cheers Mate,
-Ben