I’m still a bit of a newbie when it comes to programming for these kinds of devices, and I have run into a problem that is limiting progress on a project that is to go into a “production” environment. I’ve tried searching, but haven’t had much success
My current setup involves a C# Windows desktop application that communicates with the Panda II using a SerialPort object through USB using the CDC.
CDC + Debug works, but it is very unreliable, as after a while, the communications port seems to “crash”. The PC will continue to send commands to the Panda and the Panda will receive and process them, but when trying to send packets (less than 64 bytes) back to the PC, the USB_CDC.Write() function on the Panda will time out and return 0 and the PC will receive nothing, requiring me to restart the board for it to start working again. Everything else (inputs and outputs) works perfectly find otherwise
It seems that the port is more likely to “crash” when I have output pins connected to other components, including several MAX6675 thermocouple chips (these share a common ground and are powered by the 5v pins on the Panda) and am toggling the state of these outputs. I tried changing the physical pins with no changes to the behavior. I haven’t been able to find any sort of pattern.
Are there any alternatives to serial communication through the USB port besides having wire up a separate serial connector? I’m not too worried about the ability to debug. I tried using StartCDC() instead of StartCDC_WithDebugging() in hopes that it would be more reliable, but I could not get the code to run after deploying to the board.
It doesn’t appear to be throwing an error. It just times out, returns zero, and continues execution. I set up a breakpoint to capture when this happens, but nothing looks out of the ordinary. I am going to see if a try…catch block will reveal anything, but an unhandled exception usually causes execution to half
Edit: It looks like it might be power related. The board drives a small relay (JQC-3FF), and if direct the output to a LED in place of the relay, it works perfectly. Has anyone had much success driving relays with the Panda II?
relays are fine, but you have to be very careful about how you do the powering of them and the powering of the device on the other side. The issue to me seems like the relay is drawing too much power over the USB cable, so you should look to supplement the power with a 7.5v 1A power supply so you avoid that (which will essentially double the current capacity you’re getting from the USB cable)
When I started working with my FEZ Cobra back in January I was driving an 8 port generic IO relay board directly from the IOs using only USB supplied power. During development and testing things went smooth as silk. When we actually ran real live tests where multiple IOs were firing many relays at once we started noticing odd time-out behaviors and relays either not firing or relays going low when others went high.
As the previous poster stated upgrading to a nice reliable external power source to supplement the board worked out perfect. I just think we exceeded the limits of the USB supplied power. We wired up an independent 6V suppy to the board and things have been magic since then.
We also switched out the types of some of the relays we were using. We originally started with the big 8 relay reed type IO boards you can find anywhere but these seem to require a bit more current than we thought so we switched some of the bigger loads over to Solid State Relays and were much happier. We can also run those off the 3.3V output. They’re faster, quieter, and seem to draw less load. They work really well in PWM scenarios too.
I have not had much luck - tried applying external power to the board and it was still failing and the external power source made it more difficult to reset - it seems that it just doesn’t like having several chips/relays/etc. connected. We tried using an Arduino instead, and while it was more reliable with the serial communication, it has a different set of problems, and I’m thinking of giving the Panda II another chance if there is a way around the problem.