CM11 Status Request (C# Language)

Hi there,

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 comunicating like this:

send... [PC] 0x8b >> [CM11]

try to recive...

14 bytes

...but it's behavior is strange and blocks...

What shoul I do?

Thank's in advance.

Quina

Reply to
Quina
Loading thread data ...

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

At 4800bps it takes about 28mS for 14 bytes.

"Qu>Hi there,

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

Thanks Dave, for your reply.

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...

Jo=E3o Carias (Quina)

Reply to
Quina

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?

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

I poll the port in as loop for 50mS or until I receive 14 bytes whichever comes first.

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

Hi Dave, thanks for your reply.

Yes, I've tryed to send the complete sequence, but after the 9b there were only 00s. Do you think that this might be a problem?

"Poll" what do you mean?... (as you already might realised I'm a newbei in X10)...

Jo=E3o Carias (Quina)

Reply to
Quina

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.

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

Is your CM11 connected directly to an RS232 serial port or to a USB port with an adapter?

Reply to
Charles Sullivan

There's a standalone demo program for the CM11A on my webpage.

formatting link
It should tell you whether you have a defective CM11.

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

Hi Dave And Charles,

Thank you both for your support.

Dave: I'll download the app from your webpage, and afterwords I'll give you some feedback.

Charles: yes, I use a USB port with an adapter. Do you think that this might be a problem?=20

Best regards,

Jo=E3o Carias (Quina)

Reply to
Quina

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,

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

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.

Regards, Charles Sullivan

Reply to
Charles Sullivan

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.

Reply to
Neil Cherry

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.

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

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.

Regards, Charles Sullivan

Reply to
Charles Sullivan

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.

formatting link
snipped-for-privacy@yahoogroups.com

Reply to
Dave Houston

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.