We've experience that if you have a UDP nework (Ethernet or CAN) the following has the potential to lockup the task that uses the variables.
If the CAN network over which the UDP messages are sent is disconnected, the task that uses these variables can lockup.
If at least 1 value isn't received for every receive UDP Ethenet variable then any task that uses this variable has a tendency to lockup. -->We work around this by creating a unique task just for copying incoming UDP messages to another list of global variables that can be used by the original task.
If you broadcast Ethernet UDP to a specific IP address and that IP isn't online the controller can lockup. --> We work around this by doing a global broadcast (255.255.255.255 with unique ID) This gets broadcasted over every Ethernet port.
Yes we can work around these issues, however this doesn't seem to be as it should and the workarounds can be a little cumbersome. We do not have these issues with the CANopen stack.
Is this:
A problem/limitation of the hardware?
A bug within Codesys or at least the libraries I have.
A case where I'm unaware of some bit I can set in a data structure that basically implies. Don't throw errors if I never receive any UDP message or the destination is not there. I'll take care of this on my own?
A case where I need to keep resetting an Ethernet fault stack because the destination is not there?[/img]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We've experience that if you have a UDP nework (Ethernet or CAN) the following has the potential to lockup the task that uses the variables.
If the CAN network over which the UDP messages are sent is disconnected, the task that uses these variables can lockup.
If at least 1 value isn't received for every receive UDP Ethenet variable then any task that uses this variable has a tendency to lockup. -->We work around this by creating a unique task just for copying incoming UDP messages to another list of global variables that can be used by the original task.
If you broadcast Ethernet UDP to a specific IP address and that IP isn't online the controller can lockup. --> We work around this by doing a global broadcast (255.255.255.255 with unique ID) This gets broadcasted over every Ethernet port.
Yes we can work around these issues, however this doesn't seem to be as it should and the workarounds can be a little cumbersome. We do not have these issues with the CANopen stack.
Is this:
A problem/limitation of the hardware?
A bug within Codesys or at least the libraries I have.
A case where I'm unaware of some bit I can set in a data structure that basically implies. Don't throw errors if I never receive any UDP message or the destination is not there. I'll take care of this on my own?
A case where I need to keep resetting an Ethernet fault stack because the destination is not there?[/img]