String Interception

jjames

Is there anyway to intercept a string that is sent to a device from a module? I have a project with a 5000LC from LiteTouch and the module requests the LED status of each tracked keypad upon startup. Unfortunately it requests all 16 LEDs for each keypad, and there's 28 being tracked. Well, I figured it out that I'm only interfacing with 130 buttons of the possible 252 physical buttons, but it asks for 448 LED states. This can take up to 4 minutes before the module is done asking for all the states, and I want to lock all controls until the last LED is requested.

One thought was to create a virtual device that would act as a second middle man, but haven't quite figured out the entire process. Another thought was to add a STRING DATA_EVENT for the real device and monitor the responses and lock out the system until I have recieved 448 of them. Lastly, I considered a timeline (or a WAIT) and throw in a ballpark number until I give control back.

Any ideas, suggestions? I'm not looking for an entire code rewrite or major code implementation, just a quick way to monitor outgoing strings. It seems the approach with the least amount of hassle would be monitoring and counting how many responses I get through the STRING section of the DATA_EVENT for the real device, but can that have any negative effects?

NMarkRoberts

Not really answering your question 8^)

I tend to write modules with heavy-duty initialisation sequences so I need to stagger their startups to prevent the controller choking. I do this by assigning each module a number and in define_start:

bModuleReady = False
wait (mModuleNumber * nModuleDelayTenths)
{
InitialiseModule()
InitialiseDevice()
bModuleReady = True
}

DHawthorne

Thge only way to intercept strings is as you suggested in your second paragraph: create a virtual device, and substitute it for the real device in the original module. Then set up code in that virtuyal to pass it along to our real device according to whatever parameter you deem necessary.

However, it looks to me that you don't really need to intercept for that application. You can always parallel STRING events; the module can do it's handling of them, and you can do your own, and lock out your controls according to what you process. There is no need to intercept them and pass them on after, as I understand what you are describing. You will, however, have to add an abstraction layer to your controls. They won't be able to be locked if they deal directly with the original module. You would need to make them independent, and do a test on whther your parallel process says it's OK to initiate a command, and only then pass it on to the module. It still seems to me that this would be simpler than a full-blown intercept.

ericmedley

Somebody correct me if I'm wrong...

I think that if you added, what would in esscence be, a second DATA_EVENT in your program you'd run into problems. Remember, the module more than likely has a DATA_EVENT that monitors the same port too.

I have had AMX modify some of their modules. Perhaps you could talk to them and ask that they put some kind of intecept variable in the data_event and let you get the string coming back.

Just a thought.
ejm

DHawthorne

Consider yourself corrected .

You can have overlapping DATA_EVENTs; I do it all the time, and even some AMX moules depend on it (like the MAX UI). The main thing you need to be careful about is duplication of an action based on that event. If what the modules actually do does not overlap, they can work with the same DATA_EVENT with impunity.

The exception to this seems to be if one of the modules is a Duet module. The Duet modules seem to intercept the data at a lower level than netLinx modules, and do not necessarily pass it along to the SNAPI router for other modules to use. Not having Cafe Duet, I can't say if this is a limitation based on the design of certain Duet modules, or an inherent limitation; I've just made the obervation on working systems.

Spire_Jeff

If you need to handle data from a duet module controlled device, just send a 'PASSBACK-1' command to the virtual device attached to the duet module. I know that there were a few duet modules that did not have this feature, but lately all of the modules I have worked with have this option. In fact, right now I am adding some functionality to the Tripplite module using the PASSBACK option.

The passback option will send all incoming strings as string events on the virtual device before any processing occurs.

Jeff

DHawthorne

Spire_Jeff wrote:

If you need to handle data from a duet module controlled device, just send a 'PASSBACK-1' command to the virtual device attached to the duet module. I know that there were a few duet modules that did not have this feature, but lately all of the modules I have worked with have this option. In fact, right now I am adding some functionality to the Tripplite module using the PASSBACK option.

The passback option will send all incoming strings as string events on the virtual device before any processing occurs.

Jeff

Thanks, that's good to know

ericmedley

Thanks for the heads-up then.

I guess I assumed it because I once had a program with some spurious results and I isolated it to to DATA_EVENTS on the same device. Once I combined the things from the two data_events into one, problem solved.

It kind of made sense to me since, in theory, a single data_event is only going to show up in thread processing once. So, the thread process should, again in theory, grab the first DATA_EVENT it sees as it makes its rounds through the DEFINE_EVENT section. By the time it hits the 2nd DATA_EVENT the event item should have been processed.

hmmm, kinda strange.

thanks again.