Jump to content

Recommended Posts

On 5/7/2020 at 2:34 PM, Ausman said:

Just remember that it seems to go against the programming rules, because you repeat the use of the same system operands for each linearization.

cheers, Aus

Any remedies for this condition?

Link to post
Share on other sites

Will reusing the same operands (system or standard) in several places in program be a problem? I often use the same memory place as auxiliary variable for several calculations in the same scan.

Link to post
Share on other sites

Not at all.  I do that all the time for intermediate calculation buffers.  The only time I put different MIs in the middle of a calculation is on the rare occasion that my code doesn't work perfectly the first time and I need to figure out where the problem is.

Joe T.

Link to post
Share on other sites

One thing that bothers me with multiple linearization inputs is that when going online the y1,y2 parameters get the readings from the second AI, no matter what their store blocks command them.

Is that because of the scan time of the program and it doesn't have the time to "update" the stored values, so it "shows" the last stored values in them?

Link to post
Share on other sites

Last one always wins with PLCs.

Also remember that the update frequency of your VisiLogic is on-line mode is relatively slow. It has to go out to the PLC and read every operand value and display it. It generally take longer than a single scan to accomplish that.

Link to post
Share on other sites
8 hours ago, Joe Tauser said:

I do that all the time for intermediate calculation buffers. 

Joe, I think it would be worth expanding on this for clarification, perhaps with some screenshots.  My comments were only about the use of the linearization operands, which is somewhat different to the area you and Isakovic are touching on.

cheers, Aus

Link to post
Share on other sites

Here's an example in Visilogic where I calculate a flow rate for a dispensing gun given the time it's on and the weight of the product dispensed.  There are two guns in the system.

Gun 1:

image.png.75f7ea381a8e13b085c7e0e0f03d4db7.png

ML 7 is a scratch register that contains the result of MI 21 x 6000.  I immediately use that value in the DIV block.  Then I don't care about it anymore.

The STL View shows how the PLC actually solves this network:

image.png.58a5a4667408bbe5ef9893c8ab7f961c.png

The line following the MUL instruction is STore the output of it in ML 7.  This happens immediately, and the PLC retrieves it in order from the same memory location (ML 7) it just wrote it to.  

This also shows why it's a good idea to look at the STL View when a network doesn't act how you think it should.  It will show the real operation flow.  This is also why you shouldn't get overly complicated with your networks.   You don't win any prizes for cramming a whole bunch of logic into one net.

Gun 2:

image.png.47a21c4857e9e9b59a89f448672f56e1.png

There's ML 7 again, holding the result value for only the few microseconds that I care about.  I can use this same register as many times as I want for this purpose.

This same scratch register technique applies to Jazz or any other brand of PLC.  Move the data into your working registers and then move it out. 

Joe T.  

 

  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...