I'm having trouble to get the CM11 status request. It took me a long time to figure out how to comunicate with the CM11 (e.g. to turn On a device...) but I can do it now.
Now the problem seem to be the status requesting issue. When I send the code 0x8B to the device, it freezes or start to have a strange behavior.
I'm rather dull when it comes to C# but my VB code (using the MSComm32.OCX control) has been working for several years.
MSComm1.RThreshold = 0 'disable comm events MSComm1.Output = Chr(&H8B) 'status request start = GetTickCount Do CM11A_Status = CM11A_Status & MSComm1.Input If GetTickCount - start > 50 Then MsgBox "Timeout waiting for CM11A Status" Exit Do End If Loop Until Len(CM11A_Status) > 13 'process here MSComm1.RThreshold = 1 'enable comm events
I do not use the MSComm32.ocx... to comunicate with the serial port, I use the SerialPort object, provided by the framework .net 2.0
Never the less I've noticed something in the piece of code you've provided: - you read each byte at the time... I'm trying to read an array of 14 bytes at once; this could be the key.
One other issue:
It's a bit dificult to explain this in english, but I hope you can understand my question. The scenario is when the CM11 is working correctly and I turn on/off a device (I can do it several times with no problems) but after a while, without sending any further bytes to the control module, the CM11 starts to behave strangely and starts to send the 0xA5 byte (power off, clock set request) althoug the module was not umplugged from the power socket...
What are the possible causes for this strange behavior? Note: sending the 9b byte doesn't stop this beahvior...
I've never seen that behavior. If sending 9B doesn't clear it, it sounds like you may have a defective CM11. Have you tried sending the entire Set RTC sequence?
Perhaps. Sending just 9B usually works but I recall a few reports that it did not - most were from Europe.
"Polling" just means that rather than wait passively for the CM11A to send the 14 bytes I repeatedly "ask" the port for whatever it has received until I've accumulated 14 bytes or until 50mS have passed.
I hope the example application works for you. It runs on 3 of my machines but GPFs at initialization on a 4th. It's a RealBASIC flaw.
A USB-serial adapter shouldn't give you any problems. It's only a 3 wire serial connection. However, it can add to the time required to send/receive as it requires translation on both ends of the link.
I just tested my example app us>Hi Dave And Charles,
I've seen some unusual behavior of USB->Serial adapters compared with actual serial ports under Linux. I've assumed these are bugs in the Linux drivers but Windows drivers (for some adapters at least) may exhibit similar behavior.
E.g., a blocking read of N bytes may return after the first byte read. So Dave's polling ought to work, while expecting to get all N bytes with one read may fail.
I heard of such things and my understanding is that these USB/serial dongles are usually dongles meant for PDA's for some reason they have a lot of trouble acting as normal serial ports. I'm unsure as to why this is.
A lot of the cheaper ones don't do anything with the handshake lines. But the CM11A doesn't use any handshake lines so even the cheap ones should work as far as the hardware goes. As for driver flaws, that's a possibility, although the complaints I've seen from Windows users can almost always be traced to the missing handshake lines. They are slower than standard serial ports because they must translate from/from serial-USB at each end of the link but this isn't a major factor at 4800bps.
All the USB->Serial adapters I've tested (I have five) implement at least some modem control lines. The cheapest I have is a $10 model from
formatting link
the most expensive a $40 Keyspan USA-19HS. The chips represented among these (as identified by the Linux drivers) are an older Prolific PL2303, a newer Prolific PL2303 (in the $10 model), an FTDI FT232BM, and whatever chip Keyspan uses.
I've used all five in Linux to actuate a CM17A Firecracker with the RTS/DTR lines, and I've started using the RI line to detect pending incoming PLC signals from the CM11A. The only problems I've encountered appear to be Linux-related: When used with the latest Linux 2.6.18 kernel the RI line on the older PL2303 chip models gets stuck in the active state and the Keyspan doesn't work at all. But both work fine with earlier kernels. (Bug reports have been filed.)
I can't say what may or may not be implemented with Windows drivers, and granted, there may be timing issues with the control lines when one of these adapters is used to connect to a high-speed modem, but that's not something I've tested.
I think most of the chips used (FTDI, Prolific, Silicon Labs) have all the lines but not all adapters implement them. Keyspan is the name most often mentioned as failing. This may be because they were originally more Mac oriented where there really were no true RS232 ports.
The timing issue is inherent. I garbled the explanation but two translations have to be made for each transmission. On the PC end, the driver has to translate to/from serial & USB. On the device end, the hardware has to do the same translations. So, while the transport via USB is fast, the overall speed is actually slower than it would be for an RS232 link. This really becomes apparent when downloading firmware to an embedded device that has a serial bootloader.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.