Strange behavior DEFINE_MODULE order

maxifox

I am facing some strange things when using HWI Lutron module, i!-TimeManager and my module together. Depending on module declaration order BUTTON_EVENTs inside my module either work or do not.

My module here is a simple test and consists only a button event handler that outputs a string to dev 0... Here is what I get:

When using this config

DEFINE_MODULE 'HWInteractive'...
DEFINE_MODULE 'i!-TimeManagerMod'...
DEFINE_MODULE 'test_mod'...

- I get nothing in diagnostics (looks like BUTTON_EVENTs do not work inside the module).

When using that

DEFINE_MODULE 'HWInteractive'...
DEFINE_MODULE 'test_mod'...
DEFINE_MODULE 'i!-TimeManagerMod'...

- diagnostics tab gives

Line 1 ::

---

TEST OK

---

- 10:42:58
Line 2 :: CIpCodeMan::RunMainLine - Default 0x0050 - 10:42:58

(what is code "default 0x0050", by the way?)

Finally, with this config

DEFINE_MODULE 'test_mod'...
DEFINE_MODULE 'HWInteractive'...
DEFINE_MODULE 'i!-TimeManagerMod'...

BUTTON_EVENT does work:

Line 1 ::

---

TEST OK

---

- 10:42:58

The sources are attached. I use Netlinx Studio build 2.3.0.102 (compiler 2.2.0.112). The code runs on NI-4000, firmware 3.00.316.

Any clue what is going on? Yes, I am aware of TN#527 about mixed type order, but it is not my case although looks similar...

Reese Jacobs

Strange behavior DEFINE_MODULE order

Well, I pulled down your test files and created a quick workspace/project to test it out. I am not running V3 firmware on any of my Masters so the test was conducted on a 2.31.137 version of the firmware. I tried every module order possible and the results were always the same - the BUTTON_EVENT occurred normally and was reported in Diagnostics. I did not get any other diagnostic messages such as the one you got regarding Mainline running. Perhaps this is an issue with V3 firmware -- I can't verify this since I have not yet had the courage to upgrade .

On a different note, your test program defined the Lutron HomeWorks module baud rate as a LONG and this results in a conversion warning from the compiler since the AMX module definition apparently defines this as an INTEGER. However, the documentation also states that 115200 is a valid baud rate to pass to the module. I was just curious how someone was expected to pass 115200 to the module using an INTEGER since the last time I checked 65,536 was the maximum value one could stuff into an unsigned integer 16-bit field. If you happen to talk to AMX about your module problem, you might inquire about the baud rate as well. Note that changing the baud rate declaration to INTEGER and using 9600 did not affect the outcome of my testing. You might try it to see if it has any effect on your testing.

Reese

maxifox

It is confirmed by AMX that, most likely, it is related with 3.x firmware... Details will be available later after AMX engineering investigation.