iannicholson Posted October 24, 2014 Share Posted October 24, 2014 We have a couple of customers whose symptoms seem to tell me that their Clippers are rebooting. Communication is lost in most cases, and we have to kill PMACSERVER (we are still using PCOMM32Pro) or reboot the PC to get communications to resume. But occasionally when this happens, our LabVIEW app doesn't indicate that communications are lost, but every variable that it reads reports "1" as the value. I haven't been able to query a Clipper while it is doing this (they have already recovered from the problem by the time I am told about it), but from the looks of the screenshots I've seen, the PCOMM32Pro driver is returning "1" for every query. Shutting everything down and restarting does seem to fix the problem, until it happens again. Clipper is being used through USB. Windows 7 Pro PCs. Has anyone had this happen? Link to comment Share on other sites More sharing options...
iannicholson Posted October 24, 2014 Author Share Posted October 24, 2014 We have a couple of customers whose symptoms seem to tell me that their Clippers are rebooting. Communication is lost in most cases, and we have to kill PMACSERVER (we are still using PCOMM32Pro) or reboot the PC to get communications to resume. But occasionally when this happens, our LabVIEW app doesn't indicate that communications are lost, but every variable that it reads reports "1" as the value. I haven't been able to query a Clipper while it is doing this (they have already recovered from the problem by the time I am told about it), but from the looks of the screenshots I've seen, the PCOMM32Pro driver is returning "1" for every query. Shutting everything down and restarting does seem to fix the problem, until it happens again. Clipper is being used through USB. Windows 7 Pro PCs. Has anyone had this happen? Link to comment Share on other sites More sharing options...
Omron Forums Support Posted October 24, 2014 Share Posted October 24, 2014 Hi, It's hard to tell since I am not near the hardware, but I would suspect that the +5 VDC logic power is dipping due to a power supply problem. Can you check the red watchdog (WD) LED on the Clippers to see if that is lit up when you lose communication? Can you maybe try a different power supply in case this one is unreliable? Also, is this happening on multiple Clippers, or just one? Link to comment Share on other sites More sharing options...
Omron Forums Support Posted October 24, 2014 Share Posted October 24, 2014 Hi, It's hard to tell since I am not near the hardware, but I would suspect that the +5 VDC logic power is dipping due to a power supply problem. Can you check the red watchdog (WD) LED on the Clippers to see if that is lit up when you lose communication? Can you maybe try a different power supply in case this one is unreliable? Also, is this happening on multiple Clippers, or just one? Link to comment Share on other sites More sharing options...
chrisb Posted October 27, 2014 Share Posted October 27, 2014 We have a couple of customers whose symptoms seem to tell me that their Clippers are rebooting. Communication is lost in most cases, and we have to kill PMACSERVER (we are still using PCOMM32Pro) or reboot the PC to get communications to resume. But occasionally when this happens, our LabVIEW app doesn't indicate that communications are lost, but every variable that it reads reports "1" as the value. I haven't been able to query a Clipper while it is doing this (they have already recovered from the problem by the time I am told about it), but from the looks of the screenshots I've seen, the PCOMM32Pro driver is returning "1" for every query. Shutting everything down and restarting does seem to fix the problem, until it happens again. Clipper is being used through USB. Windows 7 Pro PCs. Has anyone had this happen? In addition to checking your +5VDC Power Supply, you may also want to check for any ground loops between the USB Ground on the Host Computer and USB Ground on the Clipper. Link to comment Share on other sites More sharing options...
chrisb Posted October 27, 2014 Share Posted October 27, 2014 We have a couple of customers whose symptoms seem to tell me that their Clippers are rebooting. Communication is lost in most cases, and we have to kill PMACSERVER (we are still using PCOMM32Pro) or reboot the PC to get communications to resume. But occasionally when this happens, our LabVIEW app doesn't indicate that communications are lost, but every variable that it reads reports "1" as the value. I haven't been able to query a Clipper while it is doing this (they have already recovered from the problem by the time I am told about it), but from the looks of the screenshots I've seen, the PCOMM32Pro driver is returning "1" for every query. Shutting everything down and restarting does seem to fix the problem, until it happens again. Clipper is being used through USB. Windows 7 Pro PCs. Has anyone had this happen? In addition to checking your +5VDC Power Supply, you may also want to check for any ground loops between the USB Ground on the Host Computer and USB Ground on the Clipper. Link to comment Share on other sites More sharing options...
Highland Controls Posted October 28, 2014 Share Posted October 28, 2014 I would avoid using the USB comms for anything other than configuration/programming. Ethernet is a much better choice. Ground loops are very common on the USB port, and I have seen large potentials between a PC and an industrial control panel powered from different sources. Link to comment Share on other sites More sharing options...
Highland Controls Posted October 28, 2014 Share Posted October 28, 2014 I would avoid using the USB comms for anything other than configuration/programming. Ethernet is a much better choice. Ground loops are very common on the USB port, and I have seen large potentials between a PC and an industrial control panel powered from different sources. Link to comment Share on other sites More sharing options...
iannicholson Posted December 2, 2014 Author Share Posted December 2, 2014 I just had a slightly older machine with a UMAC where our LabVIEW interface was freezing as it was starting, so we switched over to Ethernet (over the phone, no less) and it seems to be working again. I will have to try Ethernet with the couple Clipper users as well. I did have one customer who found a loose terminal at his 5VDC power supply, but so far he's the only one with concrete evidence of that. I think the count is up to three now, but no one has complained in several weeks... I read in the manual that a dedicated Ethernet card/port is required to be used for UMAC (and I'm assuming this extends to Clipper as well). Is this a hard requirement? This will require us to add an additional Ethernet card to each PC we build. Is a USB<->Ethernet adapter asking for trouble in this scenario? If so, we might be able to use the USB adapter for networking and the onboard Ethernet for UMAC/Clipper. Thanks for everyone's responses! Link to comment Share on other sites More sharing options...
iannicholson Posted December 2, 2014 Author Share Posted December 2, 2014 I just had a slightly older machine with a UMAC where our LabVIEW interface was freezing as it was starting, so we switched over to Ethernet (over the phone, no less) and it seems to be working again. I will have to try Ethernet with the couple Clipper users as well. I did have one customer who found a loose terminal at his 5VDC power supply, but so far he's the only one with concrete evidence of that. I think the count is up to three now, but no one has complained in several weeks... I read in the manual that a dedicated Ethernet card/port is required to be used for UMAC (and I'm assuming this extends to Clipper as well). Is this a hard requirement? This will require us to add an additional Ethernet card to each PC we build. Is a USB<->Ethernet adapter asking for trouble in this scenario? If so, we might be able to use the USB adapter for networking and the onboard Ethernet for UMAC/Clipper. Thanks for everyone's responses! Link to comment Share on other sites More sharing options...
Recommended Posts