Dear William you're really doing a great effort in replying to questions in this forum. so please if you have links, documents, or any thing support the answer , don't hesitate to attach them.

someone will use them in a way or another

William_B

Pyrus

ONLY DIRECT RESPONSES PLEASE! NO LINKS. I wish you guys to explain your way, step-by-step what I'm supposed to do.

What an odd order!
This puts me under the impression that you are lazy
and insist on being spoon fed.
I encourage you to prove me wrong.

--------------

okay... the steps as follows -
1. Download the System Manual for the S7-1200.
(no link provided as per your instruction)

Thank you all for your very quick responses! :). I have read and taken into consideration all of your responses, and surprisingly the code turned out to be just two lines. (Evidently there will be other lines for low voltage contactors and relay triggers (external outputs) but they are simple process.) 

Also, thank you for clearing the idea about the direct output power to the encoder. I was wondering if I could give it directly 24 V from the PLC. (Read some other posts about the CPU 224 (S7-200 series) and it's the only PLC (although quite old and now discontinued since 2014) is the only PLC capable of handling direct input and output at +5V with encoders. 

As per what you said about the encoder having an insufficient data, I do agree 100%. At some point I'll have to go and check the data sheet personally, provided I get the exact specification of the DELTA brand that they are willing (or should I say insisting) to use.

Back to the code, I have uploaded the encoder part of the code, and used the input as an arithmetic operator used for comparison. I gave the limit a variable (Data_Block_1.Size), and got it from a global data block, so that I may use it to link it from an HMI. Worked on some designs for it, and KTP600 or even TP600 seemed the ideal dimension for it in color, since I only own a TP177A to test on. (Both are 5.7 inches, as it occurred). 

I have uploaded a picture of the code I wrote for the encoder as requested. As stated previously in the current post, it is just two network lines. One for the encoder count, and the other for the control of the high speed counter. Now, for this case, I would like to know if the count will reach 1024 or 4096. (I have mistakenly said 1024*4=4048, when it's actually 4096. My bad :P). And if the count reaches only 1024, how can I make it reach 4096 for better precision, given the current assumptions by William_B and me?

For the TIA Portal v13 SP1, I'm afraid I'll have to wait. Although I am currently downloading all the files SP1.001 through SP1.011, I'm on hold for the trigger of the installer (the .exe file), due to software export restrictions. I have filled an extended registration form (as per given), and will have to wait for a granted request. I'm not worried though (Patience is a virtue XD). At least this way, I'll only have to download the .exe file since I have all the remaining ones.

I completely agree. That is what I'm to reach in the end, and what I'm aiming to do. The size is actually in meters. What I am aiming to do personally is the following:

Determine how many meters I get after exactly 1 revolution. Depending on that, I'll use a math operator as a multiplier or divider,etc... (Whatever the case calls for), and depending on the PPR of the encoder, just do the math and get the desired value from the HMI to the Data block value multiplied by a constant which was predetermined. 

Once this step is complete, I'm adding a break to the system drive motor to nullify any possible inertia that may remain. Once the breaks trigger (and to avoid complications), I'll trigger a 1 second timer from within the PLC to "cut" the paper. Once the cutter reaches back its initial position (I'm going to use the negative transition instruction on the proximity switch that indicates the cutter in its initial position), the system reactivates, and continues to perform the same operation over and over. An operation during constant movement specially with a cutter is far more complex, and is not required by the client (which is actually good news hehe).

Oh, and another good news, I have pictures of the motor that is to be used as well as the encoder attached to it. The picture was blurry, however, I was able to make out what the brand and the serial number of the DELTA brand encoder actually is:

It's an ES5-10CN8942 Incremental Rotary Encoder

Here is the description after I found it online:

Surprisingly, the encoder has 5 wires only, and was quite identical to the picture I saw.

Yet again surprisingly, there were no NPN or PNP specifications. All I saw was "ungated". I tried to look it up, by writing the part no and adding to it "PNP" and then "NPN" and "ungated", but instead, I got something in Japanese, and it was barely even related to the part number that was referred! LOL!

Now, "Ungated" probably has its own meaning, but I'm afraid I do not know its definition. I'll keep looking.

In any case, I hope the information provided is enough this time.

The link: http://www.starautomations.com/ACEncoder.aspx?p=Encoder

If you're not using the Z output don't worry about gated or ungated. That just describes the relationship between Z and A&B pulses.

If it's an open collector then it's NPN and you will need to do as William mentioned in his post, add a pull-up resistor.

Ah! I see... This puts things on a different angle. I honestly wasn't expecting an NPN encoder. 

Nevertheless, I'll have to use a pull-up resistor, indeed as William_B aformentioned. For this type of signal input, I'm guessing the resistance should be around 0.5 W, 1k or 2.2 kohms. Some sources proposed 3.3 khoms even. Because I checked some forums, and they were usually referring to pull down, and not pull-up resistors. Which makes me wonder about the admittance and how easily it would be affected by outside noise, stray capacitance, and electromagnetic compatibility. 

Another thing that came to mind is about a interesting read I made some time ago. It's about using NEGATIVE resistance. It does completely oppose ohm's law, but there are diodes that are used for negative resistance, such as the Tunnel diode, and the Gunn diode, which are used for high speed microwave oscillations. Could reach about 100 GHz transition frequency if need be, though I'm not certain it would help my application. 

Another question: If I am to use the pull up resistor, should I connect them to both pins? (In this case it's I1.0 and I1.1, but I am reconsidering after what you guys told me.) For now the inputs are still the same. How many ohm resistance should I add, and how may I determine it in case it is highly variable? 

Note that I'm still using 20 us speed for the pulse detection on input. Since it is starting from IB1000, I'm assuming both inputs are actively working between addresses 1000 and 1003. 

I may need the CTRL_HSC, because it seems that the high speed counter MAY change its value during the operation automatically. Basically, instead of a user coming in and putting the new addressed value, the high speed counter will automatically change it into a predetermined value, and the process goes into an endless loop until stopped by the user.

These values will be of course converted from distance to pulse, depending on the application, and will automatically be applied as the new value for the high speed counter.

So, my questions:

1. What is the value of the pull up resistor?
2. Should I put a pull-up resistor to each wire? 
3. The operating phase is still A/B fourfold. Should it be kept this way due to the new information provided about the encoder, or irrelevant?
4. The program that I have uploaded as picture in my previous post, is it correct? Am I on the right track if I am to continue afterwards?
5. Side note: Would the diodes mentioned above in the current post help? 

(Thank you note: Thank you all for the information that you are all providing me. It is helping me immeasurably, and the links are indeed helpful (but I'm just stating the obvious here XD)

Sorry, it's a Saturday and it's sunny out.

The idea of using an open collector output is to source more current than a sourcing output can. The question is, did they choose it for that reason and  the encoder is going to be placed a considerable distance from the CPU or is it just what was available.
The resistor value will depend  on the power supply, length of wire connecting the encoder to the PLC and the current requirement of the you CPU inputs, check the specs of your particular unit.
The higher the value of the resistor the slower the response but in general a value between 1K and 10K is where it will be.

Resistors will need to be placed on both lines A and B.

Are you doing the wiring of programming only?

And with regard cycle time and math functions. How fast will your encoder be rotating? calculate that and you may find that by the time you FBs do their math work the count has changed. Hardware Interrupt block is more appropriate.

Oh hey. I'm only responsible for the programming wiring, but I would still like to know how to wire it from outside. Now, William_B said that using the comparison arithmetic operator is a bad choice, and left it for others to answer for its reason. Now, I'm assuming that it is possible that the comparison may not occur on time, and the high speed counter is too fast, and the condition may become bypassed, and will continue counting, reach the highest possible value, restart from the lowest possible value until it reaches the desired value once again and MAYBE stop this time. This is what I deduced. The programming part is most important for me however, which is why my focus is tending towards it. But again, it doesn't mean I should not know how to connect it on my own.

So, here is basically how I want this program to work, and hopefully, I'll be able to draw the optimized and correct form of the ladder diagram I'm trying to get:

1. The machine is a paper cutter.
2. Multiple papers stacked upon each other will be placed to be ran on a conveyor. 
3. The knife (paper cutter) has been tested, and it is able to perform its job by successfully cutting through the stacks of paper.
4. The motor is the same for both encoder and conveyor (Asynchronous motor)
5. The encoder specs are given in previous post. (It's NPN incremental rotary encoder, 7-24 VDC).

Programming part:

1.  Motor must have a break on it, to cancel out all inertia moment left after power interrupt.
2. When the "Start" button is pressed, the encoder will read the input from the HMI, convert the unit from distance to pulse (depending on the system, calculations will be performed for it of course).
3. The encoder will count the number of pulses, until it reaches the desired amount. Once reached, the break will deactivate (meaning it will grip the motor), and the motor's power will stop.
4. The cutter will be activated, slicing down through the papers, and will return to its original position, will it will trigger through a negative transition the restart of the motor.
5. The process repeats itself.

Hi pyurus,

My apologies for not remembering  all the details of you project and I will go back to read it thoroughly.
It appears to me that the kind accuracy you detailed in your last post requires more motion control than adding an encoder.
I thought you were adding code to an existing program to include the encoder. My bad, I will review your previous posts.

As to HSC:

Go to hardware configuration and properties.
Go the the HSC you enabled
Scroll down to event configuration  and enable "generate interrupt for counter value.....bla, bla bla"
It will assign a hardware interrupt block. May be OB40.
Put the necessary HSC code that you want to execute.

Basically there are various types of OBs and there's a priority list of which OB type gets executed first. A hardware interrupt allows you  immediate access to an event. That event in your case will be reaching a specific count that you assign to HSC's NEW_RV

Pyrus

The encoder is connected to its driver, and has a 2 wires that are to be sent to the PLC. I wish to know how I'm supposed to connect these two wires to my PLC, and what function from inside the PLC (programically speaking) I am to use so that it can accurately perform the fast counting. 

 What are the details of the driver you mentioned? You may not need resistors at all.

William_B

4.
Bad news. Your code will not "cut" it.

Think physics and timings.
When you reach your position target it will already be too late to start the cutting.
The blade should have make contact with the paper already.
The reaction speed of the blade. travel speed of the blade
and the speed of the paper feed needs to be brought under consideration.

Probably you would want to synch the lateral movement
to be in synch with the paper feed.

If you are doing an in-motion cutting application, you are in big trouble.
In this case you need a motion controller running
an electronic cam application.

As I said before...   the high speed counter is the piece of the tip
that did not sink the Titanic.

5.
Converting the pulse measurement to a distance would be a good idea.
The user understands inches / mm.. not pulses.

Your thoughts?
w

William_B

engma

<snip>
because my problem is with software not hardware.

</snip>

{Set :: Mentor tone}
My dear brother...
If this is your thinking, then you are already lost.

We program because of the hardware and to compliment it.
If you do not understand how the hardware works,
then your program may very easily not do the right thing.

Case in point...  PWM vs PTO when using the H-bridge.
It is because of the hardware that I interfered.

Step0 - understand what is asked by the project and what the aims are.

Step1 - get to know the hardware and what is required. It does not need to be experimentally proven but it must be 99.5% sure from research at least. - - - in the actual hardware you are using.

Step2 - configure the hardware on the PLC.

Step3 - create a model (design) of rule based or mathematical formula to give control.

Step4 - coding

Step5 - test, evaluate, adapt.

w

 Project management 

Yikes, looks like you are doing Feed Roll Control/Cut to Length using start/Stop.  What are you using to drive your feed roll?  As William_B alluded to, your cut command must be issued when your product is stopped at the proper place, which means you need a proper position control.  If you trigger your stop solely on length, then there is additional distance traveled during the deceleration.  Whether your are stopping by brake or by using a drive on your motor, you can't change this. 

Cut-to-Length applications are not trivial.  You may want to give this a little bit more thought as to how it is executed.  Trust me, 90% of what I do is cut-to-length is some form.