Agnostic programming idea

[Dustin_M]

I am trying to create an agnostic product queue builder using PLC ladder logic.

I have a pallet conveyor and would like to be able to use a NO or a NC device in the field without changing my programming. Ideally it would become plug and play. Allen Bradley, RS Logix 5000, V20.

Is this possible?

My current application is using sensors to detect how many pallets are in the buffer. I have three sensors. So I currently can detect up to 3 pallets in my buffer. I have used a TON to add to the buffer count and a TOF to sub to the buffer count. A sensor was damaged and replaced with one that provides an inverted signal. I was curious how to go about programming this into the logic. I think if it is possible it would be very beneficial for all sorts of applications.

Thank you for your time!

Dustin

 

[dogleg43]

Agnostic?
You have my attention. ����

 

[Dustin_M]

Agnostic?
You have my attention. ����

What I mean by this is I hope to create a program in which it does not matter whether I am receiving a true or false signal. Just a signal. That way it does not matter in the field what device I am using to send a signal as long as there is one.

 

[drbitboy]

I am not sure I understand the request, but if I do then summat like the following would allow an hmi-driven bit, HmiSense, to control how an NC or NO input is interpreted, and store the result in the ObjectSense bit, and then ObjectSense would be used in the queue logic to indicate whether an object was sensed at Inp.

The HmiSense bit could also come from a spare input that is hard-jumpered to be always either 1 or 0, and then if the Inp sensor changed, changing the jumper would make the code work with that new sensor.

  Inp   HmiSense                  ObjectPresent
--] [------] [-----------+------------( )-------
  Inp   HmiSense         |
--]/[------]/[-----------+

 

[Dustin_M]

I am not sure I understand the request, but if I do then summat like the following would allow an hmi-driven bit, HmiSense, to control how an NC or NO input is interpreted, and store the result in the ObjectSense bit, and then ObjectSense would be used in the queue logic to indicate whether an object was sensed at Inp.

The HmiSense bit could also come from a spare input that is hard-jumpered to be always either 1 or 0, and then if the Inp sensor changed, changing the jumper would make the code work with that new sensor.

  Inp   HmiSense                  ObjectPresent
--] [------] [-----------+------------( )-------
  Inp   HmiSense         |
--]/[------]/[-----------+

Thanks for the input, Dr., I am not sure I understand your proposed solution.
It sounds like we are talking about a toggle or a latch/unlatch.

The first rungs are for converting a make or a break into a latch.

  Latch    Inp                Oneshot1       Latch
--]/[---+--] [-----------+------] [---------(L)-------
        |  Inp    |
          +--]/[---+

  Latch    Inp                Oneshot2       Latch
--] [---+--] [-----------+------] [---------(U)-------
        |  Inp    |
          +--]/[---+

The next couple are for a debounce. I don't want a "flickering" sensor to be 
an issue.

  Latch                                   TimerOn1
--] [--------------------------------------[5 sec]------

  Latch                                   TimerOn2
--]/[--------------------------------------[5 sec]------

Finally the timers are adding and subracting accordingly. 

  TimerOn1.Done       Oneshot3             Counter
--] [---------------------] [--------------[Add 1]------

  TimerOn2.Done       Oneshot4             Counter
--] [---------------------] [--------------[Sub 1]------

This is where I am stuck.

Above is what I started with. I am not sure how to do my "garbage collection"(keeping my count from messing up). If Latch(true) is adding, how could I ensure that, when there is not product there, it unlatches.

P.S.This is my first thread/series of posts on any forum like this and I hope I am using the tools and following the guidelines correctly.

I was just copy/pasting the code from the post I quoted. Is there an easier way to do that?

 

[LadderLogic]

Just thinking aloud… If you can use a positive one-shot (OSR) and a negative one-shot (OSF) from the same sensor input to update each counter, it should work for either sensor polarity - just divide the count value by 2.

Of course my first choice would be to use the correct sensor.

 

[L33er]

Below is my super Agnostic programming rung:

BeBit AgnosticBit DumberBit
--]/[------] [-----------+------------( )-------
BeBit AgnosticBit |
--] [------]/[-----------+

 

[drbitboy]

    Inp
-+--] [---+--
 |  Inp   |
 +--]/[---+

"To be or not to be"

To put it another way, this construction on those first two rings is a mistake, because it can be removed and not change the behavior of the rung. And once that is removed, the Inp bit is no longer an input to, and cannot effect, any change on that rung's output.

 

[Dustin_M]

Just thinking aloud… If you can use a positive one-shot (OSR) and a negative one-shot (OSF) from the same sensor input to update each counter, it should work for either sensor polarity - just divide the count value by 2.

Of course my first choice would be to use the correct sensor.

Thanks for the reply,

I will use the OSR and the OSF for the make and break requirement, thanks. My count value must go up and down, however, using the same sensor so there is no need to divide by two.

I would like to use the correct sensor as well, but my goal is for more inclusion and ease of use in the future.

 

[Dustin_M]

Below is my super Agnostic programming rung:

I feel like you don't want to help or are being short on purpose. If this is the case...no thank you...
If this is not the case I am lost.

 

[Dustin_M]

    Inp
-+--] [---+--
 |  Inp   |
 +--]/[---+

"To be or not to be"

To put it another way, this construction on those first two rings is a mistake, because it can be removed and not change the behavior of the rung. And once that is removed, the Inp bit is no longer an input to, and cannot effect, any change on that rung's output.

I did need them for the "make" or "break" status change. LadderLogic suggested a shortcut for what I originally had with one shots rising/falling.

 

[drbitboy]

I did need them for the "make" or "break" status change. LadderLogic suggested a shortcut for what I originally had with one shots rising/falling.

You may have thought you did need them, but you did not:
they were not doing anything, they cannot not change the state of the incoming rung state

Yes, ladderlogic's is probably what you want. The only question is how do you know when you want to react to the rising edge one shot or the falling edge one shot? I.e you will see an increment to a counter at each edge oneshot, but one will be rising then falling for NO prox, and the other will be falling then rising for NC prox, so you are back to the original problem.

 

[JesperMP]

The idea of the program being neutral to N.O. and N.C. sensors sounds interesting.
But is this fully thought out ?

How does the neutral code distinguish between 'pallet present' and 'hole between pallets' ?
Surely it will make a difference, or .. ?

I would make a password protected HMI screen, and in that screen have a configuration dialog for the sensors, i.e. if N.O. or N.C.

 

[parky]

I agree with Jesper or a preferred solution is stick a temporary relay on the sensor until a proper one can be used.
Is it really worth having mountains of code (assume a lot of sensors), where it is unlikely to be used, confuse people who might have to decipher it. It may work in situations where pallets are essentially the same size or the gap between them is within a set distance but really, just get stores to keep the right parts in stock.
Many sensors have light on/ dark on which is effectively the same thing you just change the mode.

 

[Aardwizz]

By "agnostic", I think what you're referring to is a having a "Configuration Bit" (CFG) that, when set, treats a NO input as "Detect" and when reset treats the same input but interprets NC as "Detect".

This is exactly what Dr. Bit Boy's logic was doing:

    CFG_Is_NO   Input      Detected

------| |--------|/|----+-----( )-

                        |

    CFG_Is_NO   Input   |  

------|/|--------| |----+

From that point on in your code, use "Detected" rather than "Input" for all your programming -- debounce logic, etc.

Wrap all of this up in a nice little AOI, and then all your code is the same no matter what kind of input you have (limit switch, photoeye). All you have to do is merely "configure" things, like whether CFG_Is_NO should be true or false, what your debounce Preset time should be, whether the signal constitutes an alarm condition, what the alarm delay is (different from debounce), and whether the "bad" state is a "1" or a "0".

Rockwell did this exact thing in their PAX library. Not that they were the first, by any stretch.