Setting Baud rate to variable
undrtkr
Junior Member
I'm writing code for a 60+ room roll out for a college. They want control of two different Elmo document cameras. These two models have different baud rates. My question is can I set a variable to a specific baud rate and insert that variable into the SET BAUD command. Here is the code I'm thinking of.
DEFINE_VARIABLE
PERSISTENT INTEGER nElmoBaudRate //Determines Baud Rate
DEFINE_START
SWITCH(cElmoModel)
{
CASE cElmo400: nElmoBaudRate = 4800
CASE cElmo4400: nElmoBaudRate = 9600
}
DATA_EVENT[dvElmo]
{
ONLINE:
{
SEND_COMMAND DATA.DEVICE,"'SET BAUD ',nElmoBaudRate,' N,8,1'"
}
}
DEFINE_VARIABLE
PERSISTENT INTEGER nElmoBaudRate //Determines Baud Rate
DEFINE_START
SWITCH(cElmoModel)
{
CASE cElmo400: nElmoBaudRate = 4800
CASE cElmo4400: nElmoBaudRate = 9600
}
DATA_EVENT[dvElmo]
{
ONLINE:
{
SEND_COMMAND DATA.DEVICE,"'SET BAUD ',nElmoBaudRate,' N,8,1'"
}
}
Comments
-
I believe you are going to need to either use ITOA() or store the baud rate as a characters. You might also want to consider TSET instead of SET.
Jeff -
That looks fine, although I don't think you need to use persistent memory for something you're going to set in Define_start every time.
The other thing you could do, just to use less variable memory is thisdata_event[dvElmo] { online: { switch(cElmoModel) { case cElmo400: send_command data.device,"'SET BAUD 4800,N,8,1'" case cElmo4400: send_command data.device,"'SET BAUD 9600,N,8,1'" } } }
There's really no reason to overly complicate it by declaring a variable
J -
Jeff wrote:That looks fine, although I don't think you need to use persistent memory for something you're going to set in Define_start every time.
one note on this statement. You almost never want to do a SET BAUD command in the startup section. In most cases the device is not even online at startup. It's best to put it in a DATA_EVENT in the ONLINE: section. That way the command doesn't get ignored. Any type of integrated master should be done this way. NI_X100 or whatever... -
I was referring to the variable that he was setting in define_start, not the baud rate. His code had the baud set in the online event, but he was setting the variable in define start every time, which means there's no real reason for it to be persistent, because its going to reset every time you reboot the master.
J -
what are the 'parameters' for them to switch between the two models?
Otherwise you could just switch the baudrate according to a button press or something... -
Jeff wrote:That looks fine, although I don't think you need to use persistent memory for something you're going to set in Define_start every time.
The other thing you could do, just to use less variable memory is thisdata_event[dvElmo] { online: { switch(cElmoModel) { case cElmo400: send_command data.device,"'SET BAUD 4800,N,8,1'" case cElmo4400: send_command data.device,"'SET BAUD 9600,N,8,1'" } } }
There's really no reason to overly complicate it by declaring a variable
J
Hm, good point. The above example would make it simpler. The cElmoModel is a constant set to 1 or 2. The installer will have to set this constant to whatever model of Elmo is being used before they compile and upload to the processor. Thanks. -
of course, if you'd like to get really creative, you can have a little fun with it
**Note, I haven't tested any of this and I don't speak Elmo, it just seemed like a fun idea so I wrote this in 5 minutes. If this turns out to be a stupid idea, sorry about it**define_variable persistent integer nElmoModel define_event data_event[dvElmo] { online: { switch(nElmoModel) { case 0: { send_command data.device,"'SET BAUD 4800,N,8,1'" send_string dvElmo,"'Version?'" wait 50 'ElmoModel' { send_command data.device,"'SET BAUD 9600,N,8,1'" send_string dvElmo,"'Version?'" } } case 1: { send_command data.device,"'SET BAUD 4800,N,8,1'" } case 2: { send_command data.device,"'SET BAUD 9600,N,8,1'" } } } string: { stack_var char cElmoResponse[50] if (cElmoResponse='Version=Elmo_400') { nElmoModel=1 cancel_wait 'ElmoModel' } else if (cElmoResponse='Version=Elmo_4400') { nElmoModel=2 } } }
As long as you can actually query the Elmo to find out what its model number is, this should work. Otherwise you'd have to set a variable (nElmoBaud) to tell you what the baud rate was when you asked it a question and just ask it anything, and tell it to keep the baud that got you a response.
I'm not necessarily recommending you use this, but it seemed like a fun way to make it so the installer couldn't forget to set the constant.
J -
Oh, I see. That makes sense. I thought you were talking about putting the SEND_COMMAND dv_my_serial_port, 'SET BAUD 9600 ETC....; command there. that was a common problem early on on this board. Been bit by it myself a few times.Jeff wrote:I was referring to the variable that he was setting in define_start, not the baud rate. His code had the baud set in the online event, but he was setting the variable in define start every time, which means there's no real reason for it to be persistent, because its going to reset every time you reboot the master.
J -
No problem, I'm fairly sure I learned not to do that myself here on this board.
On another note, has anyone ever tried anything like the little snippet I posted yesterday? Something that sends commands out at different baud rates until it finds one that works, then stores that rate in persistent memory? It seems in the abstract to me that it would work, but I'm not set up to test it. I'm intrigued by the concept, because I like being able to write code that works for multiple rooms.
J -
I did it a couple times. It works just fine. It's kinda like the old dial-up modem days where the modem has to initiate the call and determine the best baud rate. One issue I ran into was a box that would lock up when it recieved communications at the wrong baud rate. That was really goofy. I totally blame the box.Jeff wrote:No problem, I'm fairly sure I learned not to do that myself here on this board.
On another note, has anyone ever tried anything like the little snippet I posted yesterday? Something that sends commands out at different baud rates until it finds one that works, then stores that rate in persistent memory? It seems in the abstract to me that it would work, but I'm not set up to test it. I'm intrigued by the concept, because I like being able to write code that works for multiple rooms.
J
It's also useful on those occasions when you have a client who just can't leave the equipment alone and gets into the settings menu and goofs things up.
It's a good idea.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums