Could somebody please describe at what moment the rising edge mechanism detecting its states in context of writing by rising edge trigger to ModBus Slave device?
At the end of each cycle? So I have to lost one second cycle to write something?
Is it possible to reset the trigger automatically just after detection moment and before the main app cycle?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it modbus TCP or RTU ?
Screenshot of localisation the edged bit you are talking about ?
BTW, communications are almost always async. If so, then, most of the time, data is buffered before any send/receive. So planning to do some treatment on data to spare a communication cycle feels wrong.
If you run TCP, cycle time should not be a problem. I will assume you run RTU modbus. Then, you may want to do some priorities in your data. For exemple, ON/OFF orders, may be send at each cycle, while setpoints could be sent once every 10 cycle.
One more tip, Don't forget to group your requests : doing a read on 2 words is faster than doing 2 reads on 1 word. Meaning you may want to use a block read, with not used data in it, just because it is faster than doing several reads.
Same tip applies to bits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
dFx hat geschrieben:
Is it modbus TCP or RTU ?
Screenshot of localisation the edged bit you are talking about ?
BTW, communications are almost always async. If so, then, most of the time, data is buffered before any send/receive. So planning to do some treatment on data to spare a communication cycle feels wrong.
If you run TCP, cycle time should not be a problem. I will assume you run RTU modbus. Then, you may want to do some priorities in your data. For exemple, ON/OFF orders, may be send at each cycle, while setpoints could be sent once every 10 cycle.
One more tip, Don't forget to group your requests : doing a read on 2 words is faster than doing 2 reads on 1 word. Meaning you may want to use a block read, with not used data in it, just because it is faster than doing several reads.
Same tip applies to bits.
I speak about ModBus RTU in standard realization in Codesys as native device. There is an option for ModBus Slave Channel: write on rising edge trigger.
So my question is how this trigger works internally in Codesys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could somebody please describe at what moment the rising edge mechanism detecting its states in context of writing by rising edge trigger to ModBus Slave device?
At the end of each cycle? So I have to lost one second cycle to write something?
Is it possible to reset the trigger automatically just after detection moment and before the main app cycle?
So nobody knows?
Is it modbus TCP or RTU ?
Screenshot of localisation the edged bit you are talking about ?
BTW, communications are almost always async. If so, then, most of the time, data is buffered before any send/receive. So planning to do some treatment on data to spare a communication cycle feels wrong.
If you run TCP, cycle time should not be a problem. I will assume you run RTU modbus. Then, you may want to do some priorities in your data. For exemple, ON/OFF orders, may be send at each cycle, while setpoints could be sent once every 10 cycle.
One more tip, Don't forget to group your requests : doing a read on 2 words is faster than doing 2 reads on 1 word. Meaning you may want to use a block read, with not used data in it, just because it is faster than doing several reads.
Same tip applies to bits.
I speak about ModBus RTU in standard realization in Codesys as native device. There is an option for ModBus Slave Channel: write on rising edge trigger.
So my question is how this trigger works internally in Codesys.