Question About Writing Modules
TurnipTruck
Posts: 1,485
Greetings,
When writing a comm module, how do you get a string to come from the virtual device back to your main program?
For example, the physical device spits out a string saying that its power is on. How can the module say to the main program "POWER=1"
Thanks.
When writing a comm module, how do you get a string to come from the virtual device back to your main program?
For example, the physical device spits out a string saying that its power is on. How can the module say to the main program "POWER=1"
Thanks.
0
Comments
Main Program
Module Code
HTH
Vinc
Thank you. That's simple enough!
What kind of something are you referring to? I'm thinking you mean a flag to determine which way the string is going, but I don't see why that would be necessary.
As I understand it, the module variables have a module indentifier automatically added to the variables so that there is no interference between the main program and the module (or even between multiple instances of the same module). If I had to speculate, I would guess that this addition is based on the Instance Name you provide when you declare the module (hence the instance name needing to be different for each module).
As for why you would need an identifier on the SEND_STRING command if you were using it for control and feedback, an event would be generated in both the main and module for the string event regardless of who sent it. By not seperating the flow of commands and feedback, you have to be conscious of possible false postives when handling the events in the main and the module. You will also be processing the information twice and it will add to overhead. If the module only monitors the COMMAND: portion of the event, and the main only monitors the STRING: portion of the event, the code is only being run when necessary.
I think I typed what I am thinking, but feel free to ask for clarification. I'm also sure that someone out there has more details than I, and will probably correct something I typed.
Jeff
P.S.
The new Java modules use COMMAND for both sending and receiving in some of the modules I have used. This does not seem to have the same problem because the Java modules seem to have more intimate control over events being generated in the netlinx portion of code. (This is only my interpretation and not based on any tech docs )
This is one of the biggest advantages of the modules against System_Calls.
One word to differencing COMMAND and STRING level for modules.
The problem is that you'll get echoed back your commands and strings if sending them into a virtual device. So if you have a DATA_EVENT..COMMAND or STRING inside AND outside the module on the same virtual device, in worst case your system locks up.
You can see this for example if you do device notification on a virtual device and check STRING FROM and STRING TO for it, and then send a string to the virtual device.
A DUET device will not echo back, and this is why the DUET modules are working on COMMAND level in both ways.
OK, you have a module that you are passing commands to, and receiving feedback from a virtual device. If you use STRING for both, there is going to be a DATA_EVENT with a STRING handler in your module for receiving commands, and there is going to be a STRING handler in your main code for feedback. Both of these handlers are going to see all SEND_STRINGs regardless of whether they originated in your main code or from the module.
For example, I frequently use a virtual device to communicate between masters on a multi-master system. It's typical for me to have a multi-room audio system, and a local theater. Even if they are on the same master, I like to make the theater code a module, so it applies the same to that. The theater is a zone on the multi-room system, but the theater code doesn't duplicate the control code on the multi-room, I use a virtual device for the theater to talk to the other system. So, lets say my theater wants to access the media server on the multi-room; I can send a string to the virtual device that says "THEATER=MEDIA_SERVER," and the multi-room switches the appropriate zones. Well, then how does the multi-room inform the theater it actually switched? Send another string that says "THEATER=MEDIA_SERVER?" It would itself see this as another command and create a loop. So you have to identify what the strings are as they go out. Your zone could say, "COMMAND:THEATER=MEDIA_SERVER", and the feedback could be "FEEDBACK:THEATER=MEDIA_SERVER." However, if you just use SEND_COMMAND for commands to the virtual, and SEND_STRING for feedback, you know everything in the STRING handler is feedback, there is no need to prefix it or add any other indication. The command and the feedback can take the exact same form, and how they appear in the handler determines what your code does with them - act or update feedback.
I know, it's not a major big thing. You may even prefer to differentiate between your commands and feedback in the actual strings for readability's sake. But it is a convention AMX uses in their modules, and I like to follow it as well.
Code: