Difference between Input, Output, and Feedback Channels?

mstocum

Does anyone know the difference between input, output, and feedback channels on virtual devices? I haven't been able to find anything in the documentation about this.

Thanks,
Matt

jazzwyld

See if it Helps

Channels are a good way of controlling Virtual Devices or check status on a virtual device. I'm sure someone here will give you a good technical teaching, but the jist is this


If the Document reads (Control Channel or Input Channel)

If you Pulse or Turn ON/OFF that Channel something will happen

Pulse[vdvDev, 2]

If on the otherhand it is a (Feedback Channel or Output)

If you are monitoring that Channel when the state changes the Flag is moved from ON/OFF or vice versa

DEFINE_PROGRAM

IF([vdvDEV,2]=ON)
{

}

Does that help clear up the mud a little?

jjames

Another way of monitoring a channel.

CHANNEL_EVENT[dvIO,1]
{
	ON:
	{
		// DO STUFF
	}
	
	OFF:
	{
		// UNDO THAT STUFF YOU DID OR WHATEVER =)
	}
}

mstocum

Oh yes, I'm quite aware of how channels work. But NetLinx and AMX controllers refer to input, output, and feedback channels, and I'm just trying to figure out what the difference is between the three.

Device 301 AMX Corp.,NXC-VOL4 Download,v1.0.11 contains 2 Ports.
 Port     1 - Channels:255 Levels:8
              MaxStringLen=64 Types=8 bit  MaxCommandLen=64 Types=8 bit
              The following input channels are on:None
              The following output channels are on:3,6,9
              The following feedback channels are on:3,6,9

For example, above, why are the feedback and output channels the same, but all of the input channels off?

jjames

mstocum wrote: »

Oh yes, I'm quite aware of how channels work. But NetLinx and AMX controllers refer to input, output, and feedback channels, and I'm just trying to figure out what the difference is between the three.

Device 301 AMX Corp.,NXC-VOL4 Download,v1.0.11 contains 2 Ports.
 Port     1 - Channels:255 Levels:8
              MaxStringLen=64 Types=8 bit  MaxCommandLen=64 Types=8 bit
              The following input channels are on:None
              The following output channels are on:3,6,9
              The following feedback channels are on:3,6,9

For example, above, why are the feedback and output channels the same, but all of the input channels off?

Oops.

Input is probably no different than the "input" on the master, and is only on when the device receives an input on a channel?

mstocum

jjames wrote: »

Oops.

Input is probably no different than the "input" on the master, and is only on when the device receives an input on a channel?

Basically what I'm looking for is an easy way of setting control channels that double as feedback channels w/o setting off my own channel_event. Ie, channel 255 is POWER_ON, but it's also POWER_FB. If my code detects the device turned on, I'd like to set channel 255 on, but not have to have code in my channel event handler to detect that it's an internal change, not external.

DHawthorne

The input channel is used to control the device. When you push a button, you are triggering the input channel assigned to that button, which in turn generates a PUSH event on your master.

The difference between output and feedback channels is murky, but there is definitely a difference. The output channel is what responds to the input channel, depending on the device. A button, when pushed, responds to your input push with an output push, as I mentioned, to your master. A relay channel responds to your input "push" by firing the relay. Feedback channels, on the other hand, can (not often, but they can) show a different state than the output channel. If you have a set of mutually exclusive channels, and one is already on, it you fire a second with an OFF or PULSE, the first will go off. But it's feedback will remain on. The input channel accepts the commands, and the output channel reflects the action taken, but in this case, the feedback does not (at least, that is the scenario I remember, I stopped using MUTUALLY_EXCLUSIVE a while ago, largely because of this). A status check will show the channel as off, but the feedback indicator will seem to show it as ON. In these cases, you need to use a TOTAL_OFF keyword to shut off both the feedback and the output together.

But 99.9% of the time, you can treat feedback and output as the same thing, because the device programming links them. If you never use MUTUALLY_EXCLUSIVE, I can't think of a scenario that would make them not work together. I suspect there was a technical reason for this architecture that made it necessary in the engineering of the original AMX control, or there was a time when you always had to deal with them separately, and they had reasons for making it that way that have long since gone by the boards. It has the feel of a leftover paradigm that hasn't quite gone away.

mstocum

So I guess programatically there's no real way to differentiate at this point. That's a shame. My hope was that there was some undocumented feedback_on command or something I could use within a module to set a channel status, but not trigger the channel_event within my module.

DHawthorne

mstocum wrote: »

So I guess programatically there's no real way to differentiate at this point. That's a shame. My hope was that there was some undocumented feedback_on command or something I could use within a module to set a channel status, but not trigger the channel_event within my module.

Not that I know of. It's supposed to be handled by the device firmware mainly ... and the exceptions covered by TOTAL_ON and TOTAL_OFF ... which are clearly intended to catch remainders, not give you more control.

JohnMichnr

Wanted to bring this one back up as I jsut bumped into a situation where the output and the feedback channels were different and I don't know why.

Background. I usually use a half duplexing device on serial communications. I use a channel on the device to control whether I should send a serial string or not. Code looks like this:

constant 
integer nCTS

variable
char sDeviceTxBuf[xxx]

define_event

data_event[some_device]
{
   string:
   {
      //receive string
      on[some_device,nCTS]
   }
}


define_program

if(length_string(sDeviceTxBuf) && [some_device,nCTS])
{
   //pull string out of buffer - or que or whatever
   cancel_wait 'timeout'
   off[some_device,nCTS]
}
else
{
   wait 30 'timeout'
   {
      on[some_device,nCTS]
      //do something here to alert that the last command didn't go.
   }
}

This way I don't send a command until the device responds back from the previous command. It has worked very will for me for virtually every device that I have used it for. I don't even think about it now just put it in. ( I usually have some type of error tracking and timeout if the device does not respond)

Now here is the problem, I had a system with an Autopatch matrix on one master, and the controlling code for it on another master. I was using all of the above in the main master and it seemed to be working just fine. I would never see a problem as the command qued in the buffer then would spit out to the autopatch.

But I got a call from the customer that sometimes they were not getting switching (couldnt get teh karoke system to play in the bar, heavens to Betsy - you'd think the world was ending) Of course I would never see it happening. Until my last visit to the site when I was about to leave (computer shut off and in my car) when it happened again.

Looking at the various states I found:
-Tx buffer was full of commands
-on the remote master the autopatch was connected to both the output channel and the feedback channel were on(telneting into the remote master and doing a device status on that device)
-in the main master, again telneting in and doing a device status for the device (in the remote master) I found that the output channel was on, but the feedback channel was off.

The main master and the remote master had different settings for the same device. If I toggled the channel off manually (control device) then they synced back up and all my data spued forth.

Why would these two be different in the different masters - shouldn't they be the same as they are noth looking at the same device? And why would the feedback channel be different?

And... When I look at a channel [some_device,nCTS] am I looking at teh output channel or the feedback channel?

a_riot42

Interesting problem. I don't know what the exact problem is but this is why I don't use define_program. My guess would be that you are having timing problems between the define_program code and the other master. I don't think Netlinx guarantees atomicity in define_program so variables that are turned on in define_program might get out of sync with code on other masters.
Paul

JohnMichnr

a_riot42 wrote: »

I don't think Netlinx guarantees atomicity in define_program
Paul

I'm not sure I understand what you are saying there. Atomicity?

a_riot42

JohnMichnr wrote: »

I'm not sure I understand what you are saying there. Atomicity?

If you have code in define_program in a number of different files in a project or across masters, timing problems can potentially occur since there is no way (at least that I know of) to determine exactly when your define_program code will run. Atomicity is the property that requires a set of operations to execute as a unit, so that either all operations are executed or none are.

Banking software requires this so that when you make a deposit at an ATM, if a bank teller is making a withdrawal from your account at exactly the same time, the deposit is executed atomically, and then the withdrawal. Otherwise, you can make the deposit, but before your balance is updated, the teller makes a withdrawal using the not yet updated balance. I don't know how Netlinx handles these types of situations, but typically atomicity isn't guaranteed, as it is usually implemented at the hardware level.

I am not sure if that is what is going on in your case, but the symptoms sound like it. That is why I avoid using define_program as those issues can be a nightmare to try and figure out.
Paul

JohnMichnr

OK - I understand what your saying,

but Define_program slamming aside...;) (I Kneew somebody was going to mention that when I posted it - but that's another forum)

There is only one instance in the 2 masters of the channel control for the device in question. I am only controling it in the main code, with nothing referencing that device in the remote master. The serial ports on the remote master are just extension IO's for the main program. There is code running in the remote master, but it just talks to a security system ignoring the rest of the com ports.

a_riot42

JohnMichnr wrote: »

Define_program slamming aside...;)

No slam, define_program is useful for certain things. I just wouldn't want to rely on its timing to set variables that determine certain outcomes when asynchronous events occur.

From the Help File:
"With the addition of the DEFINE_EVENT section for processing events, the role of mainline in a NetLinx program becomes greatly diminished if not totally eliminated. Programs can still be written using the traditional technique of processing events and providing feedback through mainline code. However, programs written using the event table structure provided in the NetLinx system will likely run faster and be much easier to maintain."

If you share a variable across threads then there may be a possibility that you will get subtle, hard to find errors that only occur under certain circumstances involving asynchronous events. It is difficult to write code that will prevent this without slowing the system to a crawl, so I just avoid it altogether and sleep soundly knowing the system can't get itself into an invalid state.
Paul

DHawthorne

Best I can figure, remote masters create a virtual device for any locally defined device from your main master, and the link between masters synchronizes all the channels, etc. So the device is mirrored ... the "real" one on your main master, and a virtual on the remote that mimics it. If, as I also suspect, the device handler itself determines whether output or feedback channels are set, it's entirely possible, even likely, that your remote master doesn't know what device type it is, so it's not automatically making feedback follow output ... or at least not under all circumstances.

There is no documentation on this, I have concluded this from observation over the years. I am certain about mirrored devices on multiple masters; I am relatively certain there is some defined intrinsic behavior in real devices that virtuals don't have. Put the two together and you may have your explanation. Solution? Perhaps a judicious TOTAL_OFF when needed.