Recent

Author Topic: concurrent programming  (Read 353 times)

Ame555

  • New Member
  • *
  • Posts: 12
concurrent programming
« on: November 27, 2020, 06:35:52 pm »
Dear community, I am developing a system that is connected to a plant PLC through ModbusTCP protocol, this PLC sends information regarding the production process to my system, the data must be saved in function to a flag that enables a discrete value of 0 to 1, once the value changes the data related to that flag is saved, the duration of the flag is of 1 second, and it is here where it appears my doubt if I use programming without threads a flag can be activated just at the same time that another flag what would cause the loss of data, to solve this they believe that it should use multi thread or that another solution suggests me or simply I am trying to kill flies with a flame thrower, from already I am thankful for its gentle attention.

Kind regards.

jamie

  • Hero Member
  • *****
  • Posts: 4055
Re: concurrent programming
« Reply #1 on: November 27, 2020, 07:24:00 pm »
if I understand you, you are worried about data state collision between your software and the PLC over the Modbus line?

for short data burst normally you have buffers in the system that will handle holding incoming data while you prep the out going or manage the last one received.

 But my experience tells me you shouldn't have issues since you need to be the MASTER in control. Modbus devices need the master and the slave devices do not send data until they are asked for it.

 So what you maybe more concerned with is what happens to the data in the PLC while you the master is taking its time getting back to asking for the next results?
  That could be a problem but normally in those cases the PLC code needs to check for bit to ensure the last value was read if it is that important. Normally in cases where the PLC can not be expected to stop its job the PLC will use a cache buffer where the Modbus can serialize the states. In otherwords, no states get lost, just maybe a slight time shift so each time the master request a status of a bit it can then clear the last one in the PLC so the PCL can now use it again..

 so for example the Host can read a complete Byte or WORD each time and use all bits as serial cached bits.

 personally I wouldn't want to be using a Modbus connection to attempt a synchronizing of equipment.

The only true wisdom is knowing you know nothing

Ame555

  • New Member
  • *
  • Posts: 12
Re: concurrent programming
« Reply #2 on: November 27, 2020, 11:53:56 pm »
Hi Jamie thanks for responding, indeed I am concerned about the synchronization of data received from the PLC as you indicated is important to record all data, but your response reassures me a little, by the way you said you do not like the idea of using modbus for such tasks, please could comment on this protocol with which could be worked in Lazarus, thank you very much for your time.

jamie

  • Hero Member
  • *****
  • Posts: 4055
Re: concurrent programming
« Reply #3 on: November 28, 2020, 12:23:58 am »
Modbus can work if you are on a fast link, I mean really fast.
I think what you are doing is trying to catch an IO line directly from the PLC. an input to be exact.

 The PLC needs to latch this into memory and when your Modbus reads it you can then write back and unlatch it.

 Its a simple matter of having the ladder logic set a bit on if it detects an input being on, otherwise it just does not touch the bit..

so when the Modbus, your Host reads the state of this bit you can also clear the bit after a read.

There are some setups where this can happen automatically, where as the bit will clear itself once read.. You need to check that with the PLC does, otherwise you need to write back to it to clear it..

 It really does not matter which protocol you use, they all suffer the same fate, its just some are faster than others.

 If you use a ethernet link with at least 100MB you most like will be ok.

 But its not a good idea to actually be automating the control of the PLC from a Host like you are speaking of. for the most part these types of links are more desirable for monitoring the status but not for actually doing syn controlling, that is the job of the PLC..
 All you need to do is maybe set some operation bits in the PLC to behave differently and let the PLC handle the high speed issues

The only true wisdom is knowing you know nothing

 

TinyPortal © 2005-2018