90-30 High Speed Counter Preload...

Revisiting a project I did 3 years ago with a 90-30 (CPU350). Haven't touched a GE product since then. Was hoping I wouldn't have to again...

They added an APU300 High-Speed Counter card to track an encoder. I want to reset (preload?) the accumulated count with a specific number (possibly just zero) from the logic. Basically this is just to zero out the encoder each time the travel reaches a limit switch (one-shot off an existing PLC input) at the end of travel (i.e. 'Home Position'). I've studied the manual (LINK), but I'm still confused.

Can I simply use the example starting on page 4-19 (PDF page 54), with the count value I want in IN5 and IN6 (in the second BLKMOV instruction)? In other words, replace the '44332211H' with my value?

Also, in that example, is there an important reason why they use a %Q (output) bit for the one-shot? I would have used a %M bit...



-Eric

Another question...

Let's say in my counter parameters I use %AI0001 as my 'HSC Data Reference Type'. Will the current count value be in %AI0004 and %AI0005?

I'm using a 'Counter Type' B with an A QUAD B 'Count Signal' as counter 1



-Eric

The example from the manual will write a zero to the counter 1 accumulator if you replace their values at IN5 and IN6 with yours. If you don't use the same %R register addresses as the example, be careful to assign the correct values at IN4 of the first Block Move and IN3 of the second. Also be careful to specify the correct rack and slot location at the SYSID node of the COMMREQ instruction.

Using a %M bit is fine. There is no compelling reason to use %Q.

Yes, %AI4 and %AI5 will contain the 32-bit accumulator value for counter 1.

An easier way to reset the accumulator might be to wire a reset signal to terminal 5 of the module. That will drive the accumulator to its preload value. I believe the preload value defaults to zero. If you want something other than zero, you can set up a COMMREQ to establish the value. The command code in that case would be 011F (for counter 1) instead of 0101 at IN4 of the second Block Move.

I kinda figured (and hoped) you would answer this Steve...

Steve Bailey said:

The example from the manual will write a zero to the counter 1 accumulator if you replace their values at IN5 and IN6 with yours.

Click to expand...

or a non-zero value, if I choose not to use zeros, correct? I may want to add additional correction points along the travel, to correct for any encoder errors. This encoder is simply driving a display to show position.

If you don't use the same %R register addresses as the example, be careful to assign the correct values at IN4 of the first Block Move and IN3 of the second. Also be careful to specify the correct rack and slot location at the SYSID node of the COMMREQ instruction.

Click to expand...

This part I actually understand, but thanks for the reminder!

An easier way to reset the accumulator might be to wire a reset signal to terminal 5 of the module. That will drive the accumulator to its preload value. I believe the preload value defaults to zero. If you want something other than zero, you can set up a COMMREQ to establish the value. The command code in that case would be 011F (for counter 1) instead of 0101 at IN4 of the second Block Move.

Click to expand...

I can't use the hardware preload, because the switch I'm using is already connected to a 120VAC input (and used for other purposes in the program). I'd rather not add a interposing relay just to get this preload input. Plus, I'd still need to write the whole COMMREQ anyway.

Quick question about the BLKMOVE function. Since it's a 'word' move, the manual says the INs need to be in HEX. Do I need to add the 16# prefix to all values, or can I use the decimal equivalents? IOW, 0008 decimal is the same in HEX, so can I just enter '0008', or do I need to enter '16#0008'? Along the same lines, for the 'E201' command code, should it be 16#E201, or can I use the decimal equivalent (57857)?



-Eric

P.S. Interested in visiting Kearney, NJ on Monday? I wouldn't mind someone looking over my shoulder...

I didn't think so...

Yes, you can load the accumulator with any value. It doesn't have to be zero.

The system doesn't care how you enter the data. It only looks at the pattern of bits. When you use the 16# prefix you are telling the software to interpret the number you enter as hex and to write the corresponding bit pattern. With no prefix, the software will interpret your number as signed decimal, so I don't know if you'll be able to enter 57857. You might need to enter the 2's complement. I've found it generally easier to use the 16# prefix when the manual is talking about hex numbers. It makes troubleshooting go more smoothly.

Can't make it New Jersey on Monday, but I'll be in the office until around noon. I have a 90-30 HSC module so I can duplicate your setup on the bench. Send me a PM if you want contact details.

An alternate to this is using one or both of the 2 Preload Inputs (%I offset 5&6) You can setup a sensor or an output from the PLC to fire these. Use a COMMREQ or the hardware configuration to load the value to be Preloaded when these HSC inputs are triggered.
I will be playing on the home PC tomorrow afternoon, you may post your program here or email it and I will check it, no desire to visit NJ next week either.

Steve Bailey said:

Yes, you can load the accumulator with any value. It doesn't have to be zero.

The system doesn't care how you enter the data. It only looks at the pattern of bits. When you use the 16# prefix you are telling the software to interpret the number you enter as hex and to write the corresponding bit pattern. With no prefix, the software will interpret your number as signed decimal, so I don't know if you'll be able to enter 57857. You might need to enter the 2's complement. I've found it generally easier to use the 16# prefix when the manual is talking about hex numbers. It makes troubleshooting go more smoothly.

Can't make it New Jersey on Monday, but I'll be in the office until around noon. I have a 90-30 HSC module so I can duplicate your setup on the bench. Send me a PM if you want contact details.

Click to expand...

I don't like 2's comp. so generally use an ADD DINT to load a constant value into a 32bit var. I find it easy for most troubleshooters of the next generation to quickly grasp. Just Add 0 to your constant value and point the output to the %AI.

Attached is the part of my program with the COMMREQ. Am I on the right track? My HSC is in Rack 1, Slot 8.

Next issue...

I don't see it stated specifically in the manual, but I assume the accumulator value is not retained though a power cycle? Most HSC cards don't.

In this application, it would be nice to have this value retentive. I am thinking I can move the accumulator value (%AI4 and 5) to say, %R201 and %R202 every scan, since %R register ARE retentive. Then, at power up, move these values back to the HSC with a COMMREQ. I did something similar with an AD PLC, and I remember it being quite simple.

Do I need to be concerned about word types (i.e. HEX)?...

Also, if I can do this, do I need to wait a period of time after powerup before preloading the HSC? IOW, does the HSC need to initialize before it will accept a COMMREQ?

Thanks again for the help!... :site:



-Eric

I'm on the iPad without access to desktop now, so going by memory only.
Your COMMREQ looks okay at first glance, however you need to monitor the "Status Register" to verify that it was carried out without error and you should "zero" it during the same scan and before the COMMREQ function block is enabled. This is good practice with all COMMREQs.

I'll take another look at it tomorrow PM, when I have more time and are not so tired.

The Accumulated value is not retained in the module on power down, however there is a LastScan variable (%S2, I think) that you can use to store your value in retentive RAM just as you outlined above. The move can be done by adjusting the length of the MOV to 2 then address only the first word of the DINT and by using MOV WORD it will handle the bit pattern with no need to be concerned with data type.
If you use my example of an ADD DINT then you will be able to see the data in its 32bit form.
On last scan ADD DINT the %AI + 0 into the %R 32bit holding register.
After power up AND the HSC Module ready (%I offset 13) bit is on reverse this.

Also be sure to have a routine to reset errors or faults in the module by toggling the HSC Clear Error %Q bit (offset 15).

RussB said:

...you need to monitor the "Status Register" to verify that it was carried out without error and you should "zero" it during the same scan and before the COMMREQ function block is enabled.

Click to expand...

I can do that. Should I monitor the FT output as well, or is the status register enough? The status register gets reset with a value of zero at IN7 of the second BLKMV, one rung before the COMMREQ.

...there is a LastScan variable (%S2, I think) that you can use to store your value in retentive RAM just as you outlined above.

Click to expand...

That might be a better idea than moving it every scan, although in this program, scan time should not be an issue. The controlled equipment moves very, very slowly.

Thanks, Russ...



-Eric

The FT output is only turned on with a problem with the COMMREQ block it's self like a bad Task ID, so unless these are dynamic FT is not important except for initial testing.

Just added to the post above, maybe want to read it again.

RussB said:

If you use my example of an ADD DINT then you will be able to see the data in its 32bit form.
On last scan ADD DINT the %AI + 0 into the %R 32bit holding register.
After power up AND the HSC Module ready (%I offset 13) bit is on reverse this.

Click to expand...

The attached PDF is my attempt at this.

On rung 22, I'm using the 'Last Scan' bit to transfer the accumulator to %R203 and %R204.

On rung 23, I created a one-shot of the HSC's 'Module Ready' bit, and use that to write back the values at startup. I assume the 'Module Ready' should just stay on 'forever' and not retrigger my one-shot?

Rungs 24 through 26 are a copy/paste of my other logic, with the triggers replaced with my 'Module Ready' one-shot, and %R203 and %R204 as my 'preload' value, instead of zero. Can I use these %R values as they are, or do I need to 'MOV WORD length 2' them to spare %AI registers first, and use the %AIs for the preload?

I'm guessing I can safely reuse the same %R211 through %R224 that I used in my other 'reset' logic? They're just storage locations.



-Eric

Eric Nelson said:

The attached PDF is my attempt at this.

On rung 22, I'm using the 'Last Scan' bit to transfer the accumulator to %R203 and %R204.

On rung 23, I created a one-shot of the HSC's 'Module Ready' bit, and use that to write back the values at startup. I assume the 'Module Ready' should just stay on 'forever' and not retrigger my one-shot?

Rungs 24 through 26 are a copy/paste of my other logic, with the triggers replaced with my 'Module Ready' one-shot, and %R203 and %R204 as my 'preload' value, instead of zero. Can I use these %R values as they are, or do I need to 'MOV WORD length 2' them to spare %AI registers first, and use the %AIs for the preload?

I'm guessing I can safely reuse the same %R211 through %R224 that I used in my other 'reset' logic? They're just storage locations.



-Eric

Click to expand...

Sorry I didn't get to this yesterday, it snowed and the grand kids wanted to go skiing, couldn't resist. Had a great time too.

On rung 22, - Yes.

On rung 23, - This is fine but be aware that if it transitions because of an error, without losing power it will likely load the WRONG information.

Rungs 24 through 26 - This is fine BUT on Rung 25 after the BLKMOV function put an ADD_DINT IN1=%R203, IN2=0, Q=%AI4 to over-write the BLKMOV function.

Hope this is not too late to help.

Just got finished writing a long, detailed reply, and Firefox crashed...

Note to self: ALWAYS copy/paste long reply to a text file BEFORE clicking 'Preview Post'...

Okay, second attempt:

First off, thanks to both of you for all the help!...

I thought this would be an easy program change, but things never go as planned. Here's the current status:

The HSC card works. The accumulated count shows up in %AI4 and 5, and displays fine on the HMI. The issue I'm having is with the COMMREQ. My one-shot loads all the command block registers with my values fine, but the COMMREQ fails. The FT output turns on each time it executes (I added a coil to monitor it). The COMREQ status word remains at zero. I had no idea why it fails, until I got home and discovered that I'm pointing to the WRONG RACK!...

GE thinks we can't count from zero, and starts addresses, etc, at '1', yet when it comes to racks, they DO start at zero. All day, I have been pointing the COMMREQ at Rack 1, Slot 8, when I should have been pointing at Rack ZERO, Slot 8...

If this is the only problem, then I should be fine. Any other tips about the COMMREQ are welcome though, in case this isn't the only problem. I am not sure what value should be put in location 10 (IN3 of the second BLKMV). The example calls it 'Start Location of Data (R0011)'. They show an 'A' (decimal 10), but their command block starts at %R0001. Mine starts at %R0211, so position 10 is register %R0220. Should I put '16#00DC' (decimal 220) here?

The other dilemma I have is this:

There is a proximity sensor reading a flag on a leadscrew (the leadscrew provides vertical motion). Depending on the direction of travel, I add or subtract a '1' to/from a %R register (Poor man's encoder). This value just drives a bar graph on the display to indicate current location and works fine. I use a limit switch at the bottom of travel to zero the value each time it actuates, just to clean up any possible missed counts. Actually, I reset to a '1', but that's irrelevant. This also works fine.

The issue is with a power cycle. I want to retain the current value. The problem is that the limit switch is wired normally-closed, and connects to an AC input card. Therefore, my one-shot to reset occurs when this input turns OFF. Unfortunately, when power is shut off, this input turns off BEFORE the PLC stops scanning, so it sees the input turn off and triggers my one-shot, resetting the count...

Any thoughts on how to get around this? I'm thinking maybe a slight delay timer on that input, so it has to be OFF for a short time before triggering the one-shot. Long enough that the PLC shuts down BEFORE the timer expires.

Any other ideas?

I'm hoping tomorrow goes better than today...



-Eric

Sorry 'bout that.

Going to bed now, but post or email me a backup of your project and it will be a more accurate review in the AM.