HSC not reporting fast enough

[CapinWinky]

You have 4 outputs, 2^4

0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

 

[JHarbin]

On the contrary. I need 10 and the HSC can only supply a total of 8.

OK, the HSC has 4 outputs.

If you have none on that is 0000 which is a decimal 0
Output 1 on is 0001
Output 2 on is 0010
Output 3 on is 0100
Output 4 on is 1000

Now...

Output 1 & 2 on is 0011
etc. all the way up to 1111 which is a decimal 15

Again, I am not familiar with the HSC, other than what I just read in the manual, but if you can read it as a 4 bit bit-packed integer, then if you unpack the 4 bits, you have 0 to 15 states.

I don't know how you would do this with the HSC, and maybe you can't but I think that is what the one how posted his suggesting was saying.

 

[phuz]

Sure, there are a total of 16 combinations, but not exactly possible to use that as triggers.

Logically, there are 8 triggers available.

 

[Ken Roach]

I realize you have the 1756-HSC hardware already, but I wanted to mention that I am doing a project with 80 fast outputs I need to command relative to a single motion axis, and am getting really good results with the 1756-OB16IEFS scheduled output modules. They connect to the Logix operating system's motion planner via the Motion Axis Output Cam (MAOC) instruction and allow me to trigger an output with a time resolution of about 20 microseconds.

Back to the project at hand: it looks like the 1756-HSC can be configured as the triggering module for an Event Task, so you could set up a Program to be executed every single time the Input data changes.

The RA Knowledgebase [568476]confirms that the [module]:slot.I tag can be used to trigger an Event Task, but goes on to say that the data is updated "every Real Time Sample of the Counter channel".

I'm not familiar with how the "Real Time Sample" works on an HSC module in Counter or Encoder modes. There's a lot of info in the User Manual about how the Sample Rate is determined in Rate or Frequency mode.

It might be determined by the "Scaler" field, so it looks like the minimum value is 10 milliseconds. I'm not sure how it works if the Scaler value is left at the default value of zero.

 

[Ken Roach]

Update from RTFM'ing: if you leave the Scaler value at 0, the sample rate defaults to 1 second.

It's possible that your .PresentValue is only updating once per second.

Try putting a value of 10 (for 10 milliseconds) into the Scaler field for the counter channel.

You can also troubleshoot by reading the I.CSTTimestamp[0] values for each update and looking at the difference between sequential ones. That will tell you for sure how fast the updates are arriving.

 

[phuz]

Update from RTFM'ing: if you leave the Scaler value at 0, the sample rate defaults to 1 second.

It's possible that your .PresentValue is only updating once per second.

Try putting a value of 10 (for 10 milliseconds) into the Scaler field for the counter channel.

You can also troubleshoot by reading the I.CSTTimestamp[0] values for each update and looking at the difference between sequential ones. That will tell you for sure how fast the updates are arriving.

Good Lord I completely forgot about that.
Well thanks Ken. I didn't bother to RTFM because I have used these in the past, but mainly for flow totalization where scalar wasn't as significant.

Edit:
Unfortunately did not help.
Since the tray spacing is identical for all 10 shots, I just used the one output and reset the counter after each trigger. Seems to be working fine.

 

[V0N_hydro]

it looks like the 1756-HSC can be configured as the triggering module for an Event Task, so you could set up a Program to be executed every single time the Input data changes.

The RA Knowledgebase [568476]confirms that the [module]:slot.I tag can be used to trigger an Event Task, but goes on to say that the data is updated "every Real Time Sample of the Counter channel".

I'm not familiar with how the "Real Time Sample" works on an HSC module in Counter or Encoder modes. There's a lot of info in the User Manual about how the Sample Rate is determined in Rate or Frequency mode.

This is unrelated but I'll chip in on this thread on AB counter modules. I used a 1756-CFM with 4 MHz clock counter to measure the frequency of 60 Hz generator frequency with .36 mHz resolution, but it is not possible to have an event task executed with the speed control PID when the 1756-CFM reported a new frequency reading to the PLC CPU. This is unfortunate as then the new CV could have been calculated and outputs updated with the minimal amount of delay. the delay didn't matter in this case anyway. Looks like I probably needed a 1756-HSC.

 

[GaryS]

From what I can see you have 1 input to trigger the camera Yes?
are the parts spaced the same number of counts apart in the trays?
if that is the case then you only need 1 counter output.
set the counter up as a ring counter with the rollover count at counts between parts.
set the trigger output for the for the number of counts between the parts
use the Z input to reset the counter at the start of every tray
the counter will turn on the output at the set point then roll the counts over to 0
the Z input reset will start the counts at 0 at the start of the tray
use the ladder program to set the rollover value and enable and disable the output as needed
trying to read the counter value and then turn on an output based on the count value will be difficult. it will depend on the scan time of the program witch varies with every scan.
let the counter do it own thing it will be much more accurate then you will ever get in the ladder code
check the counter manual it will explain it.

 

[GTUnit]

Thats a good suggestion GaryS.
I'm surprised no one asked at what rate these triggers need to happen.
Specifically how close together.

 

[BlueAltezza]

I'm not a fan of the HSC functions on RS5000, but I've had much better results using a single counter in a ring setup and using lim functions to trigger events rather than resetting and loading values to the individual counters.
You're still at the mercy of the scan time, but unless you're going at super fast speeds the cameras will still be able to have the target within their windows.