Why is it that I can get IO counting in Opto aPAC, but for some (artificial) reason I can’t get the counts through PAC Control programming using an R2. I don’t need high speed, but standard counting would be really nice…

GetCounter doesn’t work? I haven’t used aPAC, so maybe I am misunderstanding you.

Not until I setup the count feature on a point, and that is only allowed on certain hardware. Yet, if I pull up the digital point in aPAC there is a count displayed…

My understanding… Opto is still counting behind the scenes, but it is locked out on certain hardware for unknown reasons… maybe to sell higher end products???

Interesting, which modules don’t allow counting? I would think that is a brain level feature and should work on all digital inputs, at least up to the 16 point modules***.

Since aPAC can see a count - have you tried reading the count directly from the memory map in PAC Control?

The memory map address of the counter data for a module and point can be found by:

0xFFFFF080000 + (0x100 * Module) + (0x40 * Point) + 0x10

So for the point you have on your screenshot the address should be: 0xFFFFF0804D0

You can then call ReadNumFromIoUnitMemMap:

ReadNumFromIoUnitMemMap(MYIOUNIT, 0xFFFFF0804D0, MYINTVAR);

***All of the above is for standard digital modules - HDD modules are different.

Okay, I just read the fun manual …

It isn’t the module, it is the brain that determines counting support - so EB2’s and R2’s don’t support counting EXCEPT on high density modules (since the counting is done in the module itself on HDD modules).

I thought all brains supported counting, just the EB2 and R2 didn’t support high speed counting.

I am still interested in finding out if you can read the count from the memory map and it is actually incrementing. I have an R1 here, so I can’t test this myself.

R2’s don’t support counting on HD modules either apparently. That is my setup and it won’t allow me to do it. My understanding is the counting is done on the module level in HD modules, so theoretically any unit with an HD module should be allowed to do counting (just not high speed). I discovered this accidentally a year or two ago when I accidentally configured an EB2 as an R1 and it did counting (which at the time it wasn’t suppose to be able to do). I wonder what would happen if I called my R2 an R1…

Is this a bug in PAC Control?

Hi nickvnrl,

Try using the “Get HDD Module Counters” command in the “High Density Digital Module” group.
If you’re not seeing those commands, in PAC Control, select File > Strategy Options, click the “Legacy” tab, then click on “Original High Density Digital commands” to enable them in your strategy.

I can see a few opportunities for improvement here in PAC Control, but in the meantime, I thought you should know about those “hidden” HDD commands!


Okay, that makes more sense why you see a count in the android app - it is reading the count from the memory map of the high density module. If you looked at a regular digital input module, it probably won’t show a count - or just stay at zero.

If the Get Counter command does not show for a HDD module on an R2, I would say that may be a bug, or something they didn’t anticipate. If that is the case, I would shoot off an e-mail to product support.

I would read the value direct from the memory map in the mean time.

I was wondering about that, then I saw that in the User Guide, that it was for SNAP Ultimate, SNAP Ethernet, and SNAP Simple I/O units and figured it wouldn’t work for a “modern” brain.

Interesting, that PAC control wouldn’t care about the brain type for those commands, but does for the regular Get Counter command.

Wow, looks like we’re all posting at the same time, whoo-hoo!

FYI, I find a few tickets already in our ticket database about making these HDD features a little easier to get to, but I suppose they’ve not bubbled up to the top of the list since you have other options (and we have some more fun stuff like nested subs to solve! whoo-hoo!)

Anyway, our revised-for-9.5 UGs will hopefully be more clear on these points. I also lobbied for making those HDD commands not-so-hidden, but so far no luck.

Originally those HDD features were a little clunky, with lots of bitmasks, since the mem map was so 4-channel based. So when we expanded the mem map (in modern brains w/more memory) to have lots more points, and we gave you MOST of the normal point niceties, like individually named points. But obviously we’ve not yet added all the niceties quiet yet!

I never used those commands. I just left the EB2 as an R1 because it was such a pain moving everything over. It works fine, so I leave it alone.

I did a search and didn’t find the earlier conversation. Maybe it got wiped out with the forum outage awhile ago?

This really should get fixed (or documented) in the next update.

I think your conversation was w/PSG, as I find PSG ticket: 96304 associated with the code change request for adding this! (I added more notes to that request ticket, and threatened a hunger strike…) but in the meantime, if we had a note in the command reference for “Get Counter” do you think that would help the next person (or you) trying to get a counter value from an HDD module on an R2/EB2?

Also note that in the upcoming 9.5 PAC Control, you’ll find you can easily change, say, an R1 to be an EB2 instead! Double whoo-hoo!!

I do think this would be helpful. Documentation is always a good thing.
I am fighting bad/no documentation with Compac Sort and it is horrendous trying to get things figured out and working…

On a side note, I am looking for a SQL genius to help get some info into my strategy and ultimately my groov… any takers?

Speaking of counters… How does the snap pac count? Does it increment when the input turns on or is it when the input turns off? I am getting a 1 count difference between the built-in counter and my coded counter.

//Adds 1 to the pulse count with every pulse
IF (IsOnLatchSet(Upper_Push_Counter))
  THEN  Upper_Push_Pulses = Upper_Push_Pulses +1;

Also, this appears to run faster in my groov monitor than the built-in counter.

According to the documentation, the count in the brain is incremented when the state changes from off to on. I’ve also saw it work this way on my 4 channel digital input module I have here. I would think the counters in the HDD modules work the same.

Is the built in counter greater than your strategy counter? The module may be receiving more off to on transitions by the time you check and clear the latch in the strategy.

Also, I’m a software engineer and the acting DBA at my office here, so I may be able to help you with your SQL request. I’ll send you a message with my email address.

On the SQL/database front (and since I have my head deep into 9.5 testing at the moment), I should mention that our 9.5 PAC Project release will include a much improved OptoDataLink – which is the piece of PAC Project Pro (also available separately as an add-on to PAC Project Basic), which makes it easy to “link” your strategy tags to database(s) easily, just by filling out a little “where to?” “where from?” “when?” type form. No need to be an SQL genius.

Also in 9.5, the new RESTful interface to those strategy tags will also make linking to your database easier – with no middleware required, just a little T-SQL code! But that would appeal more to those who are closer to the “SQL genius” side.

Stay tuned, and make sure you’re subscribed to OptoNews for upcoming exciting info that makes me want to use lots of exclamation points and say whoo-hoo too much!!

I am already using DataLink, I need help with the SQL side. What I am looking for, is in two different tables and need to be matched and paired up to make sense. And then this data needs to be displayed through groov.

I haven’t ever used OptoDataLink, but does it allow you to write SQL so you can write a join?

If not, you can create a view in SQL server that joins the tables and then query that from OptoDataLink.

Thanks Philip for the SQL help!
Back to counting.

My observations:

  1. The coded counter seems to be faster reacting than the hardware counter using an R2/EB2
  2. I got an R1 to demo and the hardware counting is dramatically faster than the coded counter
  3. You can skip the "hidden" legacy setup just by calling an R2/EB2 an R1... Just remember during programming only the commands for the actual hardware will work.

Since I can now use the counting feature, how do I subtract from the count when in reverse direction? I am using an inductive sensor on a sprocket, counting teeth as a primitive encoder. So when the chain goes in reverse I would like to subtract from the count.

My code for forward looks like this:

Upper_Push_Pulses = GetCounter(Upper_Push_Counter);

Simple right? So now if my reverse switch is on how do I subtract?