1734-vhsc24

Hi all,

Looking at using a 1734-VHSC24 for the first time. Looking through the documentation, it seems to show two separate modules; one with the VHSC24 part number on it as well as all the status indicators, and the other one looking fairly blank. Can anyone confirm that if I order a 1734-VHSC24 I will get both modules, or is the blank module a partner of some kind, with a separate part number that I need to order separately?

Also, the document I'm looking at says that I need the 1734-TB terminal bases. I typically use the 1734-TOPS terminal bases, and I can't find mention of them anywhere in the manual. I'd have to think that the TOP or TOPS modules would be fine, but can anyone confirm this?

I have asked my rep these questions, but he wasn't sure (I got the new guy on the job, and he promised to find out, but I'm not sure how long that will take )

Thanks!

ASF said:

...he promised to find out, but I'm not sure how long that will take

Click to expand...

Not as long as I thought, it turns out!

Apparently the second module just gives you access to extra 24V/0V/Ground connections, which would be handy depending on how you were using it and what you were connecting to it. But you can just not use it, and stick with one terminal base.

Still no answer on using the 1734-TOP/TOPS with it though...any takers?

Hello guys,

I am running an application for packaging measurement using a sick DFS60B incremental encoder (programmable from 1 to 10000 PPR). In more detail, it passes packaging on a conveyor belt and we have created an inspection station and an expulsion station (defective packaging), so we use the encoder to check at specific points of the packaging for defects (we use special sensors to check defects). ) (there are four in total). However, the problem we are having is the following: When reading the encoder in the PLC, the same means that performs "jumps" and does not enter the windows (GRT and LES) created on the ladder, ie, as if it were not continuous. .

I understand that because the VHSC24 card works at 1 MHz in counter mode, this type of problem should not occur according to our application is not even 100 KHz. For example, our case: Using 1000 PPR and the motor speed (coupling output) is 3600 RPM (in practice it is around 1750 RPM) the frequency is calculated as follows: F = (PPR X RPM) / 60. : F = (1000x3600) / 60 = 60 KHz, ie 60 KHz is much less than 1 MHz, I think this kind of problem does not occur.

Application Info:

. Studio 5000 V31
. PLC Model: Rockwell 1769 - L19ER-BB1B CompactLogix 5370
. Encoder Card: 1734-VHSC24 / C
. Incremental Encoder: Sick, DFS60 up to 10,000 PPR and HTL Electrical Interface. Using a 200 mm circumference / perimeter wheel.
. Motor Nameplate Data: 1670 RPM, 0.37 kW / 0.5 HP, 60 Hz
. Inverter: Weg CFW500, Output Frequency 62 Hz.

Card Settings we use
RPI: 2 ms
Type: Counter, but we already use it as Encoder X1
Store Count Mode: Disabled
Filter: No Filter, but we use 50 KHz and 5 Khz filters in our tests.
Counter Attenuator: 1

Wiring Diagram VHSC24
We turn on encoder A at input 0 and encoder Aret at input 1

In logic
(Structured Text) Using the PMUL instruction to convert encoder (Pulse) data to mm scale.
(Ladder) The window comparisons part (GRT and Les) and other part of the process. We emphasize that we performed the tests also only with the reading and comparison part of the data, excluding the other parts, precisely to verify the issue of Scan, but the problem persisted.

If anyone here in the forum has some information that can help us, I would appreciate it.

So I am seeing:
60kHz signal
2ms RPI
I don't see your scan time. Is it continuous? Periodic? In both cases, what is your cycle time?
Let's assume your cycle time is 2ms or less..
Your encoder is going to count 60000*.002 pulses every RPI, so 120 pulses.
Is your GRT/LES window less than 150 pulses?

ASF said:

Still no answer on using the 1734-TOP/TOPS with it though...any takers?

Click to expand...

You will no doubt have already found document 1734-sg001 chapter 4.
TB - 8pin screws with removable terminal Block
TBS - 8pin Springclamp with removable terminal Block
TOP - 8pin screws, base is all One Piece
TOPS - 8pin Springclamp, base is all One Piece

AustralIan said:

So I am seeing:
60kHz signal
2ms RPI
I don't see your scan time. Is it continuous? Periodic? In both cases, what is your cycle time?
Let's assume your cycle time is 2ms or less..
Your encoder is going to count 60000*.002 pulses every RPI, so 120 pulses.
Is your GRT/LES window less than 150 pulses?

Click to expand...

-----------
It is in continuous mode. Scan time is less than or equal to 2 ms. But the VHSC24 card is 1 MHz, so this kind of problem should not occur. Do you agree?
I do not understand why the minimum RPI value is 2 ms for a 1 MHz card.
I am using PMul to "transform" from Pulses to mm scale, the size (circumference / perimeter) of the wheel influences the calculation, in this case the Wheel size is 200mm. So the window we are working on (and need) is up to 8 to 15 units (in mm), you know?

On the contrary: I wholeheartedly disagree.
Encoder pulses are too fast for the PLC scan and too fast for the network comms. So, a 1MHz VHSC samples the signal every nanosecond, and every 2ms it let's the PLC know how many additional pulses it received.
If you want better timing, perhaps your VHSC card is one with digital outputs, which can be programmed in the card's output data, to turn on at a certain pulse count, and off at a certain pulse count.
1000PPR, Max pulses I calculated earlier per RPI is 120.
200mm/rev, max mm/RPI is 200*120/1000= 24.
So yeah, you will miss your window.

AustralIan said:

On the contrary: I wholeheartedly disagree.
Encoder pulses are too fast for the PLC scan and too fast for the network comms. So, a 1MHz VHSC samples the signal every nanosecond, and every 2ms it let's the PLC know how many additional pulses it received.
If you want better timing, perhaps your VHSC card is one with digital outputs, which can be programmed in the card's output data, to turn on at a certain pulse count, and off at a certain pulse count.
1000PPR, Max pulses I calculated earlier per RPI is 120.
200mm/rev, max mm/RPI is 200*120/1000= 24.
So yeah, you will miss your window.

Click to expand...

I understood what you said. What I meant is how the card is 1 MHz and the cpu rpi has a minimum value of 2 ms. In this case the CPU is incompatible?
Why do you agree with me that 60 KHz is usually slow for a Very high speed counter card? For our application we use 4 windows, as we inspect 4 packaging defects.
Did you talk about using the output that would work, how do I use them? I even tried to do this by setting up the windows and triggering the outputs, but it didn't work.

The VHSC24 has 2 digital outputs. You can program the on count and off count in the config data. Get a hold of the user manual and it will explain how to tie an output to a window, and how to select the start and end of the window.

AustralIan said:

The VHSC24 has 2 digital outputs. You can program the on count and off count in the config data. Get a hold of the user manual and it will explain how to tie an output to a window, and how to select the start and end of the window.

Click to expand...

Based on your freq x rpi calculation, I thought of lowering the encoder resolution to 200 PPR (the encoder is programmable).

Do you have any alternative other than using these outputs? Eg would making the program in structured text or FBD solve? Would creating a periodic task solve?

vinigusto said:

Based on your freq x rpi calculation, I thought of lowering the encoder resolution to 200 PPR (the encoder is programmable).

Click to expand...

Ah, but that has no effect on the mm/RPI value. It will still be 24.

vinigusto said:

Do you have any alternative other than using these outputs? Eg would making the program in structured text or FBD solve? Would creating a periodic task solve?

Click to expand...

Hmmm.. get yourself a controller that supports ethercat is probably the nicest solution. The IO is always so much faster...
But if you want to fix a hardware selection problem with some programming..
8mm is 667μs. Let's hope you can get a periodic task of 300μs then.
Let's call the start of your window 'x' mm.
As soon as you pass 'x-24' mm, you count down the remaining mm until you hit your target.
So as an example: x = 300mm
You get an update from your encoder, pos = 288mm.
Wait three more scans of your periodic task, and use an IOT to write to your output.

You will need to adjust for different velocities.
You will need to adjust for "well actually my IOT takes time to actually turn on my part clearing device"

AustralIan said:

Ah, but that has no effect on

Hmmm.. get yourself a controller that supports ethercat is probably the nicest solution. The IO is always so much faster...
But if you want to fix a hardware selection problem with some programming..
8mm is 667μs. Let's hope you can get a periodic task of 300μs then.
Let's call the start of your window 'x' mm.
As soon as you pass 'x-24' mm, you count down the remaining mm until you hit your target.
So as an example: x = 300mm
You get an update from your encoder, pos = 288mm.
Wait three more scans of your periodic task, and use an IOT to write to your output.

You will need to adjust for different velocities.
You will need to adjust for "well actually my IOT takes time to actually turn on my part clearing device"

Click to expand...

the mm/RPI value. It will still be 24.
-------
The calculation I made was as follows: Freq = (200 PPR x 3600 RPM) / 60 = 12 KHz. .: So 12000x2ms = 24 pulses. mm = (24 * 200) / 1000 = 4.8 mm, ie lose this value.

vinigusto said:

the mm/RPI value. It will still be 24.
-------
The calculation I made was as follows: Freq = (200 PPR x 3600 RPM) / 60 = 12 KHz. .: So 12000x2ms = 24 pulses. mm = (24 * 200) / 1000 = 4.8 mm, ie lose this value.

Click to expand...

Why divide by 1000, when you could divide by the PPR?

AustralIan said:

Why divide by 1000, when you could divide by the PPR?

Click to expand...

I'm sorry, you are correct. It was to divide by 200 PPR. Would there be any variable that I could "change" to decrease this loss? Other than the RPM.

AustralIan said:

Why divide by 1000, when you could divide by the PPR?

Click to expand...

Hi AustralIan,

Perform some tests using 1 ms periodic tasks, get better results. In this period no overlaps occurred. For a period of 1 ms, a missed pulse rate would be: Freq = (1000PPRx2600RPM) / 60 ~ = 43.33 KHz. Thus 43.33 KHz * 0.001 ms ~ = 43.33 Pulses equivalent to 8.6 mm. Is this value working with Task Periodica? One question as to what it was, what time of testing it worked with a 1mm window and still (At this speed) entered the window. I was surprised, have any explanation? Below are the tests performed.

Withou Periodic Task: Scan Time of MainTask: 2.06 ms. Card is set to mode Encoder X1 and No Filter.

With Periodic Task: Scan Time of MainTask: 2.58 ms and Overlap 0. Scan Time of PeriodicTask: 0.365 ms and Overlap 0. Card is set to mode Encoder X1 and No Filter.

In our tests, we were able to lower the periodic task period to 0.8 without overlaps. The trend is that the Scan Time of MainTask is increasing slightly.