Do already On IO channels cause an On event when the master boots?

travis

Sorry for the easily testable question, but I won't be able to test until I need to know.

If some input channel on an IO card is on, and the master happens to reboot, will I get an ON event for that channel on startup?

I want to make sure the feedback stays in sync without having to toggle the IO once. I'm not using define_program at all in this program and kind of want to keep it that way. It's all event driven.

If I don't get an ON event, are there any tricks to get the channel status?

jjames

Good question! I wanted to know the answer myself, so I tested it out and found it does trigger a channel event

channel_event[dvIO,3]
{
	on:
	{
		send_string 0,'IO #3 IS ON'
	}
	
	off:
	{
		send_string 0,'IO #3 IS OFF'
	}
}


Line     20 (15:36:29.520)::  CIpInterpreter::Run - Execute Startup Code
etc., etc.
Line     43 (15:36:30.066)::  IO #3 IS ON

travis

thanks! A pleasant surprise

nicholasjames

FYI, the same is true for channels and levels on another master.

sonny

One issue with this is synchronization. I'm monitoring some channels that send events to a duet module. The channel events are ran before the duet module is loaded, so when it completes startup it doesn't have correct status of a channel if it is on. I think this may be an issue with the color thermostat as well, the module doesn't update state and status information until the next change.

Auser

jjames wrote: »

Good question! I wanted to know the answer myself, so I tested it out and found it does trigger a channel event
[code]

I seem to recall that this varies depending on whether device holdoff is off or on on the master. Also worth testing...

chill

sonny wrote: »

One issue with this is synchronization. I'm monitoring some channels that send events to a duet module. The channel events are ran before the duet module is loaded, so when it completes startup it doesn't have correct status of a channel if it is on. ...

One more reason to stay away from Duet modules, and to stay away from using channels as binary variables. I've been doing both for other reasons, so I've never encountered this issue. Thanks for the data point.
.

nicholasjames

chill wrote: »

sonny wrote: »

One issue with this is synchronization. I'm monitoring some channels that send events to a duet module. The channel events are ran before the duet module is loaded, so when it completes startup it doesn't have correct status of a channel if it is on. I think this may be an issue with the color thermostat as well, the module doesn't update state and status information until the next change.

One more reason to stay away from Duet modules, and to stay away from using channels as binary variables. I've been doing both for other reasons, so I've never encountered this issue. Thanks for the data point.
.

In my experience (someone correct me if I'm wrong) the Duet device does not report ONLINE until the module is loaded. So if you are monitoring the Duet's online state, just like you would with any other device, you can ensure your messages aren't getting lost.

I'm curious, what are your reason(s) for staying away from using channels as binary variables? I feel they're an excellent option for binary states. They can be used in a conditional ("IF ([vdvIO, CHANNEL_1] == TRUE") so there's no reason to create a separate variable unless it's essential to track that IOs state even if the corresponding device/master is offline. Plus, Netlinx is going to allocate the memory for those 255 channels whether you use them or not...

chill

Channels -vs- variables

nicholasjames wrote: »

...
I'm curious, what are your reason(s) for staying away from using channels as binary variables? I feel they're an excellent option for binary states. They can be used in a conditional ("IF ([vdvIO, CHANNEL_1] == TRUE") so there's no reason to create a separate variable unless it's essential to track that IOs state even if the corresponding device/master is offline. Plus, Netlinx is going to allocate the memory for those 255 channels whether you use them or not...

It's perfectly fine for that sort of scenario. I was thinking more of when people use channels for things that are not boolean in nature, like projector power status. Or where a thing has several possible values, so they create a channel for each possible value, rather than one integer var. I've seen this sort of thing all too often in other people's code.

Another reason is that a channel cannot be watched and changed in debug the way a variable can. When you watch a variable you see its name, which hopefully is self-explanatory, rather than see channel 140 turn on in notifications and possibly remember what it means. I don't begrudge a few extra bytes of memory if it makes my life easier; by avoiding Duet modules, I always have plenty of memory :^)
.