Multiple Module Instances

Spire_Jeff

Just a note to those who write modules. There is a problem when using multiple instances of the same module. In these cases, the HOLD: portion of BUTTON_EVENTs is only generated in the first module declared.

The current workaround is to just copy the module and rename it with a unique name for each instance. Engineering is currently working on a fix.

One side note, If you use different devices generating the HOLDs for the modules, this does not exhibit any problems.

Jeff

P.S.
I think this may have been discussed, but I didn't find anything in a couple of searches for the info.

vincen

It looks pretty strange as bug as I always heard from guys in Dallas that module were each managed as separate programs in separe instances so it looks strange that HOLD of one modules might affect HOLDs of other modules

Thanks to share that info so we don't loose time if we encounter the issue

Vince

alexanbo

Modules aren't handled as separate threads. I had thought that too but when I was down for programmer III the trainer mentioned that this was not true and that everything runs together.

DHawthorne

Threads <> instances. Modules are instanced, but nothing in the NetLinx environment is truly multi-threaded. The instances are just stacked in a meta-mainline loop. It runs fast enough that it is often indistinguishable from true multi-threading, but it's not ... unless, of course, I am completely mis-remembering many discussions about this over the years.

NMarkRoberts

That's my understanding too

There is no threading, all the NetLinx code that you write simply takes its turn, presumably in the order it was instanced in the mainline.

This has a number of interesting implications:

(1) You can be sure that all operations are atomic; you don't have to worry about one piece of data manipulation being part-completed when another process jumps in.

(2) If you write an infinite loop or some heavy-duty code, nothing else runs until it has finished. So where practical do the heavy lifting in incremental chunks rather than all at once to avoid latency for everything else. (I can't say I've ever actually done that.)

(3) (I'm guessing this observation is an implication of the above) if you "send_string 0" a LOT of text, everything slows down a LOT.

I'm sure others have more to add.