Difference between Input, Output, and Feedback Channels?
mstocum
Posts: 120
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
Thanks,
Matt
0
Comments
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?
For example, above, why are the feedback and output channels the same, but all of the input channels off?
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.
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.
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.
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:
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?
Paul
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
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.
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
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.