Home AMX User Forum NetLinx Studio

Rookie Question

staticatticstaticattic Junior MemberPosts: 200
I have a question concerning programming. I was working on the very first code I ever wrote. The code is for a conference room that sports three touchpanels, A, B, and C. Each of them can act independently of each other. A person can be sitting in front of touchpanel A and on the touchpanel confidence monitor, can be looking at output 3 from an Extron MAV switch. Another person can be sitting in front of touchpanel B and be looking at output 7 from an Extron Crosspoint switch. The idea is if the person at touchpanel A wants to put his video source on the projectors for everyone to see, all he needs to do is touch the right screen button or left screen button. In my rookiness, I hard coded variables for IF conditonals such as; IF Touchpanel A is looking at something from the MAV, do this. IF Touchpanel A is looking at something from the Crosspoint, do this. In order to accomplish this, I hard coded the variables such as if someone picked a video source form the MAV, n_MAVSrc would go to 1. The same for the Crosspoint. Here is the problem that I haven't had yet, but I am sure it is coming. If TP A is looking at something on the MAv and the MAV variable goes high, if someone else comes along to TP B and looks at something coming off the Crosspoint, that variable is going to go high and the MAV variable is going to go back to 0. So, if the person at TP A, then decides to place his source on one of the projectors, nMAV_Src is going to be low, so the IF conditional will erroroneously be false. Instead, what I need to accomplish, if the person at TP A decides to put his video on one of the projectors, as soon as that event is initiated, the Netlinx needs to know what that person is looking at and act accordingly. I was thinking I need to utilize PERSISTENT CHAR for the Extron switches and then utilize that array in conjunction with a TP index. I am having problems getting that to work. I was then thinking I should send out a string to the Extrons, see what output is being watched at said touchpanel and then act accordingly. That route seems like an extra step, but anything is better than hard coding variables. Thanks for your time.


  • staticatticstaticattic Junior Member Posts: 200
    After reading what I had written, I also had the idea of local variables. Something like when TP A is looking at a particular output, that variable is stored. Whenever the user at TP A hits "left Screen" for example, the code would look at that variable and then act accordingly. Am I getting close to a good answer?
  • staticatticstaticattic Junior Member Posts: 200
    Never mind, it can't be a local variable since a local variable is restricted to the statement block where it was declared. How about a global volatile variable?
  • staticatticstaticattic Junior Member Posts: 200
    I think I have a solution. It works out fine in my head, now all I need to do is code it. I have a 24 port MAV and a 32 port Crosspoint. I was treating them as seperate objects. If the source initaites on the MAV, it takes a different path to the projectors as compared to the Crosspoint. Instead of looking at them seperatly, I am thinking if I create one array something like:

    PERSISTENT CHAR cSWTInputs[56][25]

    I could then have the MAV be the first 24. That way, if I utilize a GET_LAST, if the index is less than or equal to 24, do something. If the index is greater than 24, do something else. Now I just need to get the ideas out of my head and get them on paper in such a way as to make them work...
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    First, it's best to use modules.

    Build a MAV driver module and a Crosspoint driver module. They might be the same module if the two have similar command sets and behaviours, but you need two module instances.

    Build driver modules for each of your displays. Make all of these device driver modules able to accept commands from other modules, possibly via virtual devices.

    At least one of these modules (the projector driver) needs to be able to handle conflicting commands from separate touchpanels. If I were making this system, I would build a quite separate module which resolves those conflicts, in order to retain the reusability of the main driver module. Commands would be sent to the Resolver modules "Switch on!", "No, switch off!" and it would think "At least one user wants this on at the moment", or "The last input selected is 3", track required state and pass on the appropriate command when required state changes.

    You haven't provided the all-important diagram but it appears that each touchpanel has a "private" display which it owns, and it is also able to send signals to the "public" display.

    The switcher drivers apparently don't need to resolve conflicts because there are no conflicts. You refer to touchpanel users viewing different switcher outputs from time to time. I think you mean inputs. Your code is controlling what is sent to a given output, most of which are "private" and not contended for. A given input can be sent to many outputs, so there is no contention there either. There is contention for the output to the projector, but I think you're stuck with accepting whatever was last selected.

    Now build a Control module and instantiate it three times, one for each independent touchpanel. This handles the UI.

    There are a variety of sources, apparently some of them Composite and some of them VGA or whatever. Build a table of available sources, characterising each with its name, the UI button number associated with it, its input number and its signal type.

    A small variety of button pushes come from each UI. "Select source" and "Switch off" are the same type. (I usually don't have a "Switch on" because what would it do?) "Switch off" just means "Set source to null." The other type of push is a toggle - "Do / don't send to projector as well"

    Your control code is simple because it is table-driven.

    When a source select button push is received, scan the table to find which source it represents, and make that the new source. When the selected source changes, first resolve the old source (just to be neat and tidy) by switching off that link in the appropriate switcher. Now send the new switch command to the appropriate switcher.

    If any source is selected, switch on the local display, and tell it which input to use depending on the type of source signal.

    If you are also sending to the projector, tell the Resolver module the same.

    Note that the control code described here handles these things independently, in the same way that the driver modules are independent of one another and of the control modules. It's a rookie trap to try to code every combination of circumstances in one great big IF tree.
  • staticatticstaticattic Junior Member Posts: 200
    Wow. Now that is fancy. I have never done any of that before, so I am interested in trying it out. Good thing I already have a working product for them. I am going to have to do some serious finger fiddling to get this working. Experience is the best teacher though. Besides, the worst that can happen, when I upload the code, the master could burst into flames. I haven't had that happen yet, so I think I am doing pretty good. ;)
  • staticatticstaticattic Junior Member Posts: 200
    I have dinked around with my code quite a bit. After spending much time rewriting quite a chunk of it, I have come to accept the fact that this project is better left as is. I did learn a lot, particularly about multidimensional arrays. At this point, I am going to have to say, next time I'll know what to do from the beginning and I'll write the code accordingly. Gong back over what I had originally done to "fix it" is rapidly turning into a complete do over. On to bigger and better things...
  • REBUILD_EVENTREBUILD_EVENT Junior Member Posts: 127
    ..next time I'll know what to do from the beginning and I'll write the code accordingly.

    I'm telling this to myself all the time for more than a year now... :-)
Sign In or Register to comment.