Priority inputs

[BC SYSTEMS]

Hi,  

I'm using an input to increment a DM value in a program we use on our standard panels.  DM value is used to change between LCD screens as we need to display data on the LCD

One niggle I have is that when I energise the input via a standard push-button, the PLC doesn't always see the input change state so the DM value isn't incremented.

After several attempts the value increments and the screen changes however this process can be somewhat frustrating.  

The program itself uses half the available program space, and I assume the reason for the intermittent reading of the input is due to the PLC resources being used elsewhere but I thought the scan time would be quick enough to pick this up??  Is there any way I can measure the scan time?

Can I prioritise this input into the PLC program?

Cheers

[garysdickinson]

Look at the end forum entry "Debounce Interupt ??" for a two different approaches for measuring the PLC scan time

It's pretty hard with using ladder logic to bog the PLC down to the point that it can miss an input generated by a human finger.

Instrument your code and figure out where the PLC is spending it's time.

Gary D.

[BC SYSTEMS]

Hi Gary,

I've been through the code and removed some of the 1 second contacts but the scan time is still slowwwww.

I added the  rung from your thread:

     0.24
----|/|----(0.24)

Output 24 flashes on and off in an but hangs in the on and off state for >2 seconds in between moments of fast flashing.

I do have a lot of custom functions (approx 50), one of these is a modbus master, currently the modbus device is not connected so there is probably some delay in the communication time-outs I'm sure.  I'll rem this code out tomorrow to see if that helps

The above aside, I would expect the PLC to pick up the input, especially as I hold the input high for 5 seconds!!

If you want to see the code I would be happy to email the program to you for comment.

Cheers

[support]

When the PLC sends out MODBUS command it waits for a response, and if it doesn't get a response (because no slave is connected) it retry another 2 times (you can change that using the SETSYSTEM command).

If you have run enough failed MODBUS read/write commands within  one PLC scan, then you would have slowed the PLC execution time so badly that you can miss an input.

In your program code you may want to use an input/relay to enable/disable functions that send MODBUS command when the slave is not connected.

[garysdickinson]

[size=14]OMG!!![/size]If you can actually see the LED flashing, your scan rate is pretty slow.  The 2 second pause is very interesting.

As you may have guessed the PLC evaluates  inputs at the start of each scan.  With a low scan rate the PLC WILL ABSOLUTELY miss some short duration inputs.  If a scan take 2 seconds, you could push an button several times during that scan and the PLC will never see it.

I'd be happy to look at your code.  If I has some ideas on how to get a bit better performance, can I post snippets of the code on this forum?

You can send it to the email address in my profile.  

It is not possible for my to put my email address into this message.  The Singaporean sensors block the correct spelling of my family name and substitute "thingy" for the first four letters.  Very funny, but very silly.  You can enter Phuket (famous Thai resort city) and not get it blocked even it it sounds pretty obscene in English.  

Gary D(thingy)ickinson.

[BC SYSTEMS]

Hi Gary,

I disabled the modbus master and the PLC is now working without a glitch.

Is it possible to run the modbus master code in a separate sub routine to help the scan time even when the modbus device is present??  The modbus read commands does seam the slow the scan time down even when the comm's is good.

I suppose I could detect the read error and disable the read commands via some relays and timers for a period before trying again??

Anyway thanks for the info.

Cheers

[garysdickinson]

Good luck on finding the culprit.

The PLC firmware behaves as if everything is a single thread.  So there is no real mechanism to allow custom functions to have a life of their own.

About all you can do is ensure that your custom functions execute quickly and evoke them carefully (only when needed).

I never poll for an external event in a custom function nor waste time using Delay statements.  I, typically, implement this type of code using a state machine using the PLC Sequencer logic and custom functions to handle what can't be done in Ladder logic.

I've got a big system that uses external A/D converter connected to the PLC via RS-485.  This RS-485 protocol is similar to ModBus in that a command is sent to request data from the A/D converter.  If I don't get a response from the A/D converter or I get a crappy response, then I set a RELAY to indicate that the A/D converter has failed.  This same RELAY is used by the Ladder logic to block any future calls to the A/D read custom function.

I divide big time consuming custom functions up into smaller pieces. I use RELAYS set by each custom function to start the next custom function on the following scan cycle.  This is typical:

• The custom function to get raw A/D data is invoked once a minute. If there is a timeout or crappy data is returned, this function sets one or more RELAY(s) to indicate the failure.
• On the next cycle another custom function converts the A/D data from an ASCII string to several scaled integer values.
• On the next cycle a custom function validates the integer values.  If the values are wacky, I RELAY(s) are set to indicate that either the failure. The system has fall back modes to keep things safe in the event of sensor failures.
• On the next scan cycle I manage active control of heaters, chillers, fans and lighting based on the validated A/D values.
• On the last scan a custom function updates a LCD display.

This may sound like a lot of work, and it is. However it allows me to do a lot of computing without causing the PLC to become non-responsive to rapidly changing inputs.

Have a good weekend,

Gary D