Home AMX User Forum NetLinx Studio
Options

Errors with G4 channel codes above 255, especially channels that are multiples of 256

I ran into what I believe to be logic errors with G4 panel (at least the MVP-8400) channel codes above 255, especially any channel that is a multiple of 256. I apologize in advance for the length of this post but if you bear with me I think you?ll find this interesting.

Tests were performed with an MVP-8400 (latest firmware 2.57.54) and an NI-700 (latest firmware 2.95.214.) TP file created with TPDesign4 (latest version 2.5.0) and I used TP4 for all TP file transfers performed with these tests.

Finding #1 - You can?t turn ON any TP channel that is a multiple of 256 (256, 512, 768, 1024, etc) on a G4 panel if that channel is the highest button channel that exists in the touch panel file.

Procedure used to verify Finding #1.

1) Load an empty source code file into your master (just to eliminate programming from the equation.)

2) Create a new, one page TP file.

3) Add one button to the page and set the channel code to 256 and feedback to channel.

4) Transfer the panel file.

5) From Control a Device in Netlinx Studio try to turn the button ON by turning channel 256 ON. You can?t.


6) Now add a second button the page and set the channel code to 257 and feedback as channel.

7) Transfer the panel file.

8) From Control a Device in Netlinx Studio try to turn button 256 ON by turning ON channel 256. Now channel 256 works and the button will turn on.

9) You can repeat steps 3-8 and find the same results with any button that is a multiple of 256.

Finding #2 ? You can?t turn ON any TP button channels 256 and above in the ONLINE event for the TP without adding at least a WAIT 1 for any channel above 255.

Procedure used to verify Finding #2.

1) Add one more button the TP file and set the channel code to 255 and feedback to channel. The TP file should now have three buttons, channels 255,256,257.

2) Transfer the panel file.

3) Compile and load the following code:
DEFINE_DEVICE

dvTP	= 10001:1:0

DEFINE_EVENT

DATA_EVENT[dvTP] {
   ONLINE: {
      ON[dvTP,255]
      ON[dvTP,256]
      ON[dvTP,257]
   }
}

3) When the program boots and the TP comes ONLINE you will see that only button 255 will turn ON. Button channels 256 and 257 remain OFF.

4) Modify the program to add a WAIT 1 as follows, compile, and download.
DEFINE_DEVICE

dvTP	= 10001:1:0

DEFINE_EVENT

DATA_EVENT[dvTP] {
   ONLINE: {
      ON[dvTP,255]
      WAIT 1 {
	 ON[dvTP,256]
	 ON[dvTP,257]
      }
   }
}

5) When the program boots and the TP comes ONLINE you will now see that all three buttons turn ON.


Finding #3 ? You can peg the output of the master by any regularly scheduled feedback loops that try to turn ON any channel (of an ONLINE TP) that is the next highest closet multiple of 256 of the highest channel code in a TP file along with any channels higher than that. (I couldn?t think of any way to phrase it any more succinctly. Hopefully someone else can. This one is easier to explain by example)

The Netlinx Master is smart enough not to generate output traffic to ONLINE TPs every time it reaches a feedback line, it only does it when it thinks it?s a change of state. So if you have a program like this:
DEFINE_DEVICE

dvTP	= 10001:1:0

DEFINE_PROGRAM

ON[dvTP,255]

?and you monitor the output LED of the master you will see it flash when the TP comes ONLINE and then the output remains quiet. You can also verify that by enabling and monitoring the notifications output.

Now to better explain and demonstrate the problem:

1) Delete the last button you added to the TP file (channel 257). There should be two buttons remaining, 255 and 256.

2) Transfer the panel file.

3) Compile and load the following code: (changing channel feedback from 255 to 256)
DEFINE_DEVICE

dvTP	= 10001:1:0

DEFINE_PROGRAM

ON[dvTP,25[b]6[/b]]

4) You will see once the TP comes online, the Netlinx Master output LED will flash continuously. And you can verify that by enabling and monitoring the notifications output. (Also any reference to any channel above 256 will cause the output to flash.)

5) Compile and load the following code: (I know the 1 to 1 FOR loop appears ludicrous but it exasperates the issue and better demonstrates how one can peg the master?s output and also demonstrates how slow a FOR loop can be.
DEFINE_DEVICE

dvTP	= 10001:1:0

DEFINE_VARIABLE

INTEGER x

DEFINE_PROGRAM

FOR(x=1; x<=1; x++) {
   ON[dvTP,256]
}


6) You will see once the TP comes online, the Netlinx Master output LED is pegged. Don?t enable and monitor the notifications output because Netlinx Studio will hang.

7) Go back to the TP file and bring back the third button, channel 257. (I love the undo/redo of TP4. It?s saved my butt plenty of times)

8) Transfer the panel file.

9) You will see once the TP comes back online, the Netlix Master output LED will flash and then go quiet.

There is another obstacle for every multiple of 256 along with the channels above. So if your highest channel number in the TP file is anywhere between 257-512 then every feedback reference in code to button channels 512 and above will cause the same problems as described above.

Anyhow, I thought I would throw this information out there. I ran into a situation where I was working on some code for a remote site. Instead of downloading the code to the remote site I mistakenly downloaded to the NI-700 in my office. My heart almost stopped when I saw the output light pegged on my NI-700. I knew that wasn?t a good sign and I was sure I screwed something up with my feedback.

I started going through all my routines trying to figure out what was generating all the traffic. I then downloaded an earlier job and saw the same results and really started to question how the heck I could have missed this erratic behavior on two straight jobs. I started sweating blood. So then I loaded the MVP with the touch panel file associated with the job so I could troubleshoot it further and after the TP file was loaded the NI-700 went silent as I expected in the first place. I then download a blank TP file and my NI-700 went crazy again. I never imagined that a dormant TP file could affect the output of an NI.

About a year and a half ago I had written a job where I couldn?t get the feedback to work properly on the ONLINE events for the TPs. Sending variable text always worked but for some reason some channels didn?t respond properly. It was always the same channels that didn?t work right but I didn?t see a correlation at the time. I gave up trying to get it to work the way I thought it should and added a WAIT 1 to all my feedback routines in ONLINE events from then on and then every channel worked as expected. It?s always bothered me that I couldn?t get an explanation as to why it didn?t work without the delay. Now I know why, the channels that didn?t respond as I expected were above 255.

One final finding, if the line:

SET_VIRTUAL_CHANNEL_COUNT(dvTP,4000)

?.is added under DEFINE_START then all the problems I?ve discussed disappear. According to TN# 578 this command refers to virtual devices. But since a device is a device is a device I tried adding the line to see what would happen and it cleared up the channel anomalies.

I hope some of you made it through to the end of this post. :) Maybe this is all common knowledge and I?ve just been ignorant of the facts all alone. Or maybe it?s just my setup but I really don?t think that?s the case. If anyone out there can confirm or refute my findings by following the outlined procedures above I?d appreciate it.

Thanks for listening.

Comments

  • Options
    Errors with G4 channel codes above 255, especially channels that are multiples of 256

    Joe,

    I did make it through the description to the end - very odd problem. I have not encountered this problem with any MVPs on my jobs but then I do not use channels above 200 very often.

    As for TN578, the only way I can see it being relevant was if you were doing a combine of the MVP with other devices and therefore introducing a virtual device into the mix. It is in that case that I understood the virtual device needed to be configured using the various SET_VIRTUAL_* commands otherwise the virtual device would have negative impact on the combined devices (G4 panels) similar to what you are seeing now. If you are not combining the MVP with other panels, then this should not be a problem and the SET_VIRTUAL command should not be required.

    Reese
  • Options
    DHawthorneDHawthorne Posts: 4,584
    Thank you. This explains a problem I have been having recently with some panel feedback that I commented out from sheer frustration. Now I can get it back in - because it was imported from an existing system that required 255+ channel numbers, but now has it's own port, I can just bump my channels down and be back in business.
  • Options
    Spire_JeffSpire_Jeff Posts: 1,917
    Thanks for the indepth investigation. At one point, I vaguely remember having problems with the high channels and I never took the time to figure out the problem. I just found that using channels below 255 worked so I made more use of ports than channels. It's nice to know how I can use channels over 255 if need be.

    Jeff
Sign In or Register to comment.