SNAP PAC EB2 brain is returning -539 in the controller message queue.
The brain is only referenced in two block2 and runs ~100 msecs between blocks and ~10 msecs after the last block before the first is read again.
Power is good.
SNAP-PAC-EB2 brain has been replaced.
Ethernet cable has been replaced.
Any ideas?
Does this error relate to communication with the SNAP-PAC-EB2 brain or is there an issue with a module on the SNAP-PAC-EB2?
In debug, if you double click the IO unit and change the Enable Comm to Yes, does it start working?
Do you have a “Enable Communication to I/O Unit” command in the strategy? This command needs executed whenever there is a loss of connectivity to the IO unit. Opto22 has a chart you can import that handles this:
https://www.opto22.com/support/resources-tools/downloads/io_enabler-for-enet-pac-brains-1-01-zip
In debug mode the enable comm is green/yes.
The strategy has the io enabler chart that you referenced…which I think is doing its job hence the green/yes in the enable comm in debugger.
Could it be that ~10 msecs delay after the last block before the first is read again is on the threshold of requesting the “MoveIoUnitToNumTableEx(MCC1_Brain1, Brain120_nTable, 0, 32)” too often…need more delay? I will test when the customer allows for a download.
Those are blocking calls - so the frequency of reads shouldn’t cause this. Are you able to read from the IO unit through PAC Manager, inspect? Can you do it consistently? Could be a network issue - maybe duplicate IP if it is intermittent. From your log it looks to be intermittent based on the varying timestamps.
I’m hoping that you did a forum search for -539.
There are only a few results and they are all worth a read.
This one has some tips that @philip just eluded to…
Yes, we can consistently get to the IO unit through PAC Manger…inspect.
Yes, it is intermittent…but is happening often. We will look for a duplicate IP address.
Yes…searched forums and knowledgebase. Like you said…not much there.
Update:
The customer asked us to increase the delay from 10 msec to 100 msec. The number of errors reduced significantly. Then they asked us to go to 500 msec. We haven’t seen any errors since then.
I think @philip is right, there is probably still an ethernet communication issue we haven’t found yet.
We checked for duplicate IP addresses but did not find any.
