High Speed Digital Input

In my application I am going to need to both totalize gallons and produce gallons per minute based on a high speed digital input block I am going to install. I am using the IDC5-Fast. I have never done one of these applications before and I’m looking for some information on “how-to” Can anyone help me out?

Hello ScaDunk,

Welcome to the OptoForums!

What other hardware/software are you using? I’m guessing you have a PAC brain or controller there on the same rack as your SNAP-IDC5-fast module’s rack, I’m hoping a SNAP-PAC-R1? And you plan to use our (free!) PAC Control Basic to write a flowchart-based strategy to gather your totalize data then do something with it, perhaps monitor the value via a mobile phone using [B][I]groov[/I][/B]? Or stick the values in a database?

Lots of options here, so depending on the parts you have and where you’re headed with this I’ll have different suggestions.

FYI, the On- and Off- time Totalizing happens a the brain level, just need to configure that point as a a totalizer and it starts totalizing, super easy (especially if you’re using PAC Control).

Also keep in mind we offer [U][B]free training[/B][/U] and [URL=“http://www.opto22.com/site/support.aspx”][U][B]free support[/B][/U] all here in lovely Southern California!

Can you tell us a little more about your application?


I am using Pac Control to program a R1 Contorller. I am using Pac Control Pro. I am not using groov at this time. I am using OptoOPCServer with GE iFix on the SCADA side. I also Have some variables from some other programming I am trying to read/write with my SCADA program. Is there a way to do that? The flow chart programming is new to me so I’m learning, but it’s slow going. I’m used to standard programming language at the moment. I’m trying to figure out the best layout for my charts for everything I’m trying to accomplish. I’m sure there are good rules of practice, but it’s a different way of thinking and a different layout of how everything looks in my head… I went to the class about 5 years ago, but it’s been a long time. It was a good starter class, but I would love to get a better idea of how to layout my charts and examples of how to do certain things. I’m sure there are good practices and bad practices as there are with any programming technique/type. I’ve been trying to find that on the site.

Do you work at Opto22?


Hi ScaDunk,

Yes, I’m happy to say I do work at Opto 22, along with [U][B]ben orchard[/B][/U] who chimes in here on the OptoForums often as well. More [URL=“http://www.opto22.com/site/meet_your_hosts.aspx”][U][B]about us and other OptoVideo hosts here[/B][/U].

We do have a [U][B]“best practices” tech note[/B][/U], developed with a lot of input from some of our more experienced OptoForums contributors! That gets into many of the topics you mentioned.

FYI, while our flow charting tools/blocks are favored especially by those with little or no programming experience, some programmers will have a flow chart with just the (required) block 0 then a single OptoScript block. In [U][B]this post[/B][/U] I talk about how, even though I’m a recovering programmer, I prefer and recommend a mixture of both.

I’m not sure what you mean by “some variables from some other programming I am trying to read/write with my SCADA program.” OptoOPCServer is the piece you need to move data to/from your 3rd party HMI to tags in or out of your strategy. And there are several other options for moving data… are you talking about a C# program or something you’d like to integrate into the mix?

BTW, did you get your SNAP-IDC5-fast configured as a totalizer, for those gallons you’re measuring, mentioned earlier?


I am still looking for IDC5-FAST instructions. I haven’t got that controller up and running yet.
For the Variables I’m talking about…I didn’t know how to get any variable to show up through OPCServer. I think I figured it out though. When I first started with Opto gear I was just getting my older equipment, E1s and E2s, to talk via OPCServer to my SCADA in which most of my older programming resides. What I was doing was using PAC Manager (which I affectionately refer to as PACMAN) to create my OTG files. I figured out that I should use PAC Control instead because then any variables I set up are also automatically loaded into OPCServer. I think that’s where I was getting messed up. So I have rewritten all my old gear to run of one main S1 controller so that any control I have to do with them will come off that instead of the SCADA Server.

So I do still need some Ideas to use the IDC5 fast for totalizing…
I am also looking to take input into my strategy to grab Hand off and Auto values from my server. Is there a typical way to do that? I started by just creating a Integer 32 variable called RecTankAuto, one called RecTankHand, and one Called RecTankOff, but I was wondering if there was a better way to do it. Each one would be taking an 1=on and 0=off value. I couldn’t find a boolean variable that would only take 1 and 0. Is there one? Other PLCs I have worked with just have a mimicked Digital Input block I have used for this feature. I may switch it to be RecTankMode and use 0=Off, 1=Hand, and 2=Auto for my modes. I just didn’t know if there was a good practice on how to do that. This is where I thought I wish I could see some other more experienced opto programmers and how they have written their strategies. A lot of people would bring in an integrator, but we can’t do that. I’ll definitely keep posting when I need something though.

PACs don’t support a boolean data type, but using an Int32 for just one bit isn’t such a big deal since you have lots of memory (see this tech note). Also, as you pointed out, using Mode = 0, 1, 2 is a good way to solve the same thing with just one tag!

We also don’t support CONST values exactly, but you could name some int32s will all caps (common naming style for a constant) and call them TANK_MODE_OFF, TANK_MODE_HAND, and TANK_MODE_AUTO with values of 0, 1, 2. Better than using 0, 1, 2 int32 literals since you can search for those “variables” later, but you can’t search your strategy for 2 later if you want to figure out where you’re setting that mode to TANK_MODE_AUTO, for example.

For your IDC5-FAST, just let the brain part of your R1 do the totalizing. All you have to do is in your strategy is configure the point as a On- or Off- totalizer:

Then use this command to get the value from the brain: GetOnTimeTotalizer(From Point[B])

[/B]Hope that helps!

Hello again Mary,

  1. I got this project done last year, but I need another solution that is close to it. I have a EB1 out in the field and I want to do the same thing as I was doing with this post. The only problem I for see is if I have comm issues during the meter calculations. Here is a screen shot of how I am doing the calculation on the R1 where the IO is local to the Controller so there isn’t much possibility of comm issues:

I have a S1 controller at the plant that is connected to the same network as the EB1. I know it’s possible to do the meter calculations the same way I have done here, but I foresee an issue with messing up the total gallons amount if there is communications loss. How would you handle that?

  1. On another note, I haven’t had to communicate between two separate IO units before. What is the best way to do that. Currently most of the programs that I have just do their calculations locally and aren’t worried about each other and my SCADA just reads and writes their values remotely via the OPTO OPC Server. I am not branching out and have a couple different controllers that need to talk to each other to get a few values. One of them needs to know when the other has the correct value to run and the other is this EB1 and S1 situation that would be calculating totals and gpm at a distance on the network.

Tell me what you think!

Thanks, Dunkin

Hi Dunkin,
There are a few options for sharing data, depending on your hardware configuration and firmware version(s). You mentioned an S1 and an EB1. How many do you have of each, and which needs to know about the other? Of course, a strategy running on an S1 can have multiple EB1s in it (so having a “master” S1 or controller is often the simplest method). But sounds like you’re talking about peer-to-peer, perhaps? Multiple S1s that they need to share info?
Need details!

There will be several different ones that I will be doing. There are two locations where there will be EB1s communicating with my Main S1 located at the server rack. The EB1s are located in the field. The S1 is what I will be using to totalize the HSD inputs at the EB1 location so i need to be able to totalize at a distance and deal with comm issues in my totalizing program.

The other one is between an R2 and an R1 where I will just be sharing some simple values back and forth. Mostly Boolean values in essence saying are you ready? yes, I’m ready, and things like that back and forth to each other.


Hello Mary,
I’m just checking in to see if you got my reply?


OptoMary is out of the office for a bit…

My thoughts… Since you are using an EB1, configure the input as a counter and do the counting on the EB.
That way, if the comms go down, it is still counting.
Have a timer on the S1 that is reset every time you read the count, that way if the comms go down, you know how long its been since you have got the count.
The S1 has a persistent variable that keeps track of total counts and thus total gallons.
From there some math in the S1 will give you your flow rate.

There is no difference when talking to more than one I/O unit from an S1. You just need to be sure to use an I/O enabler chart to get the I/O back online if the comms do drop.
That chart is included in the files on your computer, or you can download it from the Support section;

If you have more than one controller that needs to share data, best to use the scratchpad area.
There are many commands in PAC Control to make use of that area super straight forward.

Hello Ben,
I remember you from my time there at class several years ago. We hung out quite a bit to go over some stuff.

So, the Counter on the EB would be counting up all the time? No get and clear like I’m currently using? How high can that counter go up to?

Currently right now my chart does a get and clear every second to grab the pulse count and then divides by the k factor to get gallons from the meter. Then I add that to the totalizer and do some multiplication to get gpm. The gentleman that comes to calibrate our meters said it’s working great and really accurate.

The timer that resets every time I get the count is just to use for calculations of the gpm and such correct? So my thoughts are, I would just be able to use the same check every 1 second that I’m doing now and then if the comm is down it would add itself to a total seconds counting variable which would reset the next time it can get a new number and use that as my multiplier to get gpm… I would also have to subtract my current total pulses value from my old total pulses value to get pulses since last comm. What value do I check for to see if comm is actually down? Is there a certain value that is passed when comms are down when you do a move?

Do typical water meters (I use the Seametrics ip101s line most of the time) need your high speed digital block or can I use the other block you talked about in your blog? How do you tell when you need the HSD?

The exact same commands work for the EB as the PAC R.
No difference in that regard.
Thus, in effect, you can use the exact same chart for the core (when things are on-line and communicating Ok).
As you point out, if its off line, you just need to keep track of the time, the counts will still be happening at the EB.

Regarding the check (and get back online) for comms, I would be sure to use the I/O enabler chart that gets installed with your PAC Project. The same chart can be found on the website, under the support tab here;
The chart comes with a nice doc that explains how to use it, and PSG will be able to support you if you use this chart and have any questions.

Regarding the module, check the on/off times of the water meter and just match it up with the freshness and on/off times of our digital module.