M1 serial expansion port and Ethernet.

[AnotherOne]

Here's my current headache. I have a M1XSP serial port as port 1. I want to use this port to send VERY specific strings to a lighting controller.

I also have an ethernet interface. To use the ethernet interface you must set "yes" to the following globals - 35, 36, 37, 38, 39 and 40.

HOWEVER!
Now that I have global 37 set, I'm getting all the output change messages on serial port 1.
This is because in the RS232 protocol document it states:

This transmission update option transmits the updated status whenever it
changes and is enabled by setting the location TRUE in the M1 Control Global
Programming Locations 37. Example: “Xmit OutputChgs–ASCII†(Yes or No)
The Output Change Update will also be transmitted out M1XSP Serial Port
Expanders that are configured in the Generic Mode.

Since my serial port is generic, I'm now getting this crap.

How do I change the characteristics of my serial port so only my commands appear?

 

[Spanky]

If you are not using the Outputs on what ever is connected to Port 0, turn off the Output change messages at Global 37.

If you need the output change message at Port 0, then a non generic lighting controller would be the answer such as UPB....

The generic XSP port will get alot of the Port 0 messages.

 

[AnotherOne]

Here's what the documenation for the XSP states:

"As a serial port expander, it expands the RS-232 communication ports of the M1 for multiple connections to most any type of equipment that communicates using serial ASCII commands. i.e., Personal Computers and many types of equipment which feature an RS-232 communications connection."

Turning off global 37 does solve my problem. And I left port 1 connected to hyperterminal for 15 hours and the only messages I ever got where the output ones (no zones, log events, etc). Even though all globals are set TRUE. So this seems inconsitant (the fix is to turn off the output ones NOT to turn on the others!!!)

And replacing my litetouch system is not an option for obvious reasons.

It would seem that this is a design issue. The way I would have expected it to be done is that device on the other end of the serial port would send a command to begin accepting messages and another to end. Sort of like the connect and disconnect on the elkrp.

 

[Steve]

I guess it would be nice for Elk to add Litetouch as the 14th supported lighting protocol...

But I don't understand something - granted if you enable the Globals, you get alot of stuff out the serial port, but does any of that really interfere with Litetouch? So I guess what I am saying is who cares how much other stuff is being spit out of the XSP as long as the very specific strings you send are being sent properly and received and acted upon by Litetouch. Am I missing something?

 

[AnotherOne]

Two things

1. The elk strings plus my strings can arrive too fast and the lite touch misses my string - that's how I discovered the problem.

2. There is a small possibility they could become a valid litetouch string.