Allen Bradley counter HELP !

AndyP

Member
Join Date
Feb 2003
Posts
8
I’m using an Allen Bradley 5/03 with some energy monitoring software. A pulse from a meter every kW comes into the PLC via a digital input. The monitoring software polls the PLC every hour to retrieve the number of pulses for that particular hour. The problem I have is that I therefore need to reset the counter after every poll (once an hour). I don’t really want to use any form of timer within the PLC incase the software doesn’t poll the PLC at the correct time. Therefore I'm looking for a way of detecting that the register has been polled via the RS232 port, and if so, to reset it to zero.

Is there any way of doing this? Any other methods/suggestions would be very helpful! Thanks
 
The easiest, most reliable way to reset the counter in the PLC would be to have the monitoring software sent a reset pulse to the PLC once it has read the counter value.

If you're using a commercial monitoring package that you purchased, I'd be surprised (and disappointed) to find that this is not an option.

If you're using a roll-your-own monitoring program, then I'd suggest adding reset capability to it.
 
If the messaging is coming from another PLC then after your message read for the data do a message write - put some value into a bit register and use that data to reset your KWH counter. If you are polling direct from SCADA then use the SCADA package to write a reset value directly after polling for the update.
 
Thank you for the replys, the PLC is being polled directly from the commerical software package called I-Historian (by Intellution) via RSLinx (by AB). The RSLinx package being used to provide an OPC interface. There doesn't appear to be any write options within the I-Historian package. I agree about sending a reset message from the software, if only I could get it to write something....anything!

Perhaps there is something within the RSLinx side that could detect the communications and then send a reset command.

Thank you for your inputs.
 
Andy, to where this count came from OPC-Server, are there some
application or is it going to Excel-sheet ? Give me a hint.
 
Instead of a counter (CTU) instruction which stops counting at 32767, try something like this:

Cumulative_Count = Cumulative_Count + Increment

If Cumulative_Count > 30000 Then Cumulative_Count = Cumulative_Count - 30000

Now your KWh count will always be in the range of 0 to 30000. You'll need to add a script in your monitoring software to deal with the case when the latest sampled value is less than the previous value.

When you think about it, this is how the electric meter on your house works. The software that the utility company uses to calculate your bill knows how to figure the bill correctly when your meter rolls over.
 
Gents.

From the OPC server interface, the I-Historian stores the PLC data within its database, and is then viewed using an add-in in Excel.

I could sort the problem out in Excel, looking at the latest number and taking it away from the previous, but i would obviously be much nicer to sort the problem out at the source.

Regarding the Cumulative_Count idea. That is a nice way of reseting the counter, but it will still give an incrementing count in the PLC everytime the data is polled. The software needs an hourly figure, eg. hour 1: 500kW, hour 2: 250kW. Doing it using an Cumulative_Count will therefore give 750kW for the second hour, if you see what I mean! So it would still need to be reset after each poll/hour to get hourly data.

Not so easy!! ;)
 
You could let the PLC take hourly samples of the cumulative count and move the values into a table. Set up a new file, say N17 with 24 elements. Then put the accumulated value sampled at midnight into N17:0, the 1 AM sample into N17:1, the 2 AM sample into N17:2, etc.

Instead of the cumulative value in the table, you could do the arithmetic in the PLC and put the hourly incremental data into the table.

Once the data is in the table, you have 24 hours for the logging software to fetch it before it gets overwritten.

I could sort the problem out in Excel, looking at the latest number and taking it away from the previous, but i would obviously be much nicer to sort the problem out at the source.
I don't necessarily agree with that statement. You can do mathematical calculations and logical operations in both your PLC and Excel. Excel is a better tool for doing mathematical calculations than a PLC. A PLC is a better tool for doing logical operations than Excel.
 
Interesting Problem!

I played "Be the Computer" and I think I came up with something...

This assumes that the History Program is not too stupid...

The History Program can read data in the PLC. I assume it can also read bits. I wonder if it can save information and then make judgements with that information. If it can...

The History Program simply needs to know that the current reading is valid.

In the PLC, the KW Pulses are counted into Reg-A. Every Hour, the PLC copies Reg-A to Reg-B. The History Program gets KW Info from Reg-B. It doesn't know about Reg-A.

Now, the History Program needs to know if the data it is reading is valid. That is, the History Program needs to know if the current data in Reg-B is the latest update. The History Program needs a way to know that this particular reading is indeed valid.

The History Program needs to see a "Data Valid" signal before it grabs the data in Reg-B. This can be accomplished by means of an ODD/EVEN Bit in the PLC. Whenever the PLC updates Reg-B with the latest count from Reg-A, the PLC flips the ODD/EVEN Bit.

When the History Program goes to fetch the data from Reg-B, it first looks at the state of the ODD/EVEN Bit.

If the state of the ODD/EVEN Bit is the same as it was on the last reading, then the data in Reg-B is NOT current! The History Program continues checking to see when the ODD/EVEN Bit changes state.

If the History Program sees that the state is NOT the same, then the data is valid. The History Program then grabs the data AND the current state of the ODD/EVEN Bit.

Again, this assumes that the History Program has the ability to make these judgements.

If you can't use this idea directly, then maybe it opens other possibilities to you.
 
Unfortunately I have not RSLinx and VisualStudio in same PC so I can't do VisualBasic Application at the moment for you.
I hope there are suitable ActiveX-control or DDE with RSLinx OPC-Server for VB.


VB application (ActiveX or DDE component) reads Counter value ones per our via OPC, put result to database or log-file and writes its copy to FeedBack variable for reseting via OPC-Server.
Then application reads counter via OPC and when it is zero, releases writed variable to zero and counter in PLC releasing (via OPC-Server).

In PLC when Feedback value <> 0 must pulses count to temp counter and copy to counter when feedback is 0.
 
I checked my AB documentation.

Take a look at Status bit S:2/5

Incoming Command Pending Bit (Channel 1)

This bit is set when the processor determines that another node on the network has requested information or supplied a command to it. This bit can be set at any time. This bit is cleared when the processor services the request (or command).

I your logging package is communicating over channel 1, that bit might be what you're looking for. The on-to-off transition would be an indication that an external request has been processed.

Of course, if you're using channel 0 for communication, it won't be of any help.
 
Well I'm glad know one has gone straight to the solution; I would hate to think I missed something obvious!

Re Steves’s Idea:
I can follow your logic, but think to much intelligents is being given to the polling software. The software is effectively split up into different tags/channels. It starts to poll, starts at tag 1, looks at a register, grabs the data, and saves it into its database with a time/date stamp. That’s tag 1 finished. It then moves onto tag 2 (the next meter) and so on. The data cant be split up into 24 parts, and then ‘reassembled’ in the database. Each tag on the database just gets one point to look at in the PLC. I guess that one electric meter could have 24 tags, with each tag collecting data every 24 hours, but it would be pretty messy in the database.

Re: Terry’s Idea:

The history program is stupid! I’m not aware of any facility within the history software to check bits. However, perhaps the PLC could prevent the data from being accessed, perhaps by changing one of the communication options, (eg odd/even bit or baud rate etc), then the software would go away empty handed. It could keep trying, say every 5 minutes, allowing the PLC to calculate the hourly data, on the hour and place the answer into a register.

I don’t think there is enough control over the polling software to give it rules when communication errors happen, but I believe it would just keep trying.

Re: seppoalanen

Sounds possible. I don’t have enough knowledge writing Active-X components to really comment, nor know how to actually install the thing!

General
Perhaps there is scope for a combination of all the ideas, but most of them assume the polling software to be a little smarter or would rely on the polling software and PLC to be working at exactly the same time base, something that isn’t going to happen.

Maybe I could wire up a cable from the PLCs processor comms LED to a digital input to know when the comms is active, I could then take a digital output to a relay to disconnect the comms cable, update the registers and then turn the relay off ! :D
 
Last edited:
Re Steves - Status bit S:2/5

That sounds a little more promising. I’m note sure if I could update all the registers with the hours data before the polling software got it. If the bit is simply changing when a request is received it wont prevent the comms until the PLC registers are updated. If I set it up the other way round, looking at the bit set just after the reply has been sent to the polling software, then the data would be one hour late all the time.
 
Last edited:
The way I read it, the bit gets set by the CPU when it detects a command initiated by channel 1. The read request from the logging software would be an example of such a command, provided that the software is communicating via channel 1. The bit remains set until the SLC has responded to the command. In your case it would remain set until the SLC has sent the requested data back to the logging software.

If that is a correct interpretation, then you should be able to go back to your original concept and use the on-to-off transition of the bit as the event that triggers a reset of the counter.

I'm not an AB expert by any stretch of the imagination, so you'd better do some experimenting to figure out how the bit actually works. Either that, or maybe Ken or Allen will pick up on this thread and set us straight.

Once again, if the logging software is using channel 0, then all of this is pointless. I didn't see a similar flag for channel 0. Unfortunately, I suspect that the logging software is probably using channel 0. Channel 1 is DH485 protocol, which usually requires an additional license fee. Channel 0 can be DF1 or Modbus, neither of which require licensing.
 
Steve,

It may work. I'm using the standard RS232 port, not the DH485. However, if I thought I could get it working, it would maybe worth considering moving to DH485.

I think it would still need some thought. I would want to ensure that the register was reset as quick as possible after the poll, to ensure no data was lost. Perhaps some delay/timer could be used, possibly some sort of buffer routine. Not easy to try without getting the DH485 side sorted out. I'd be a bit concerned purchasing the additional hardware without knowing if it is going to work, or even ensuring I can toggle an event based upon the S:2/5.

Still, its the closest solution yet. I very much appreciate your efforts, Thanks
 
Last edited:

Similar Topics

Hello guys, I have created a program where I count the high speed inputs of a flowmeter and create pulses per second to check the flowrate. Next I...
Replies
5
Views
1,746
Hello! We have a drum rotation machine controlled by a AB SLC 500. The drum rotation inputs comes from a encoder into a 1746-HSCE. We are using 2...
Replies
0
Views
1,128
Hello! We have a drum rotation machine controlled by a AB SLC 500. The drum rotation inputs comes from a encoder into a 1746-HSCE. We are using 2...
Replies
5
Views
2,196
Hi, I am using L24ER-QBFC1B. Does anyone have a sample using embeded HSC? I need to read angle and doing reset this counter. Tnak you Mario
Replies
1
Views
1,125
I want to keep wallclocktime roughly the same on 5 different controllers using factory talk alarms and events so the timestamps in the alarm log...
Replies
7
Views
7,523
Back
Top Bottom