开云体育

The last byte is the checksum, but you're right, the checksum for on
should be 1E, so \x05\x01\x18\x02\x1E

On Tue, Feb 15, 2011 at 3:05 PM, Chip <cfm@...> wrote:

?So what does 1E do? ?What goes inbetween Off and On? ?:)

? ?- Chip


--- In Crestron@..., Jeremy Weatherford <xidus.net@> wrote:

Manual you posted has &#92;x05&#92;x01&#92;x18&#92;x01&#92;x1D for power off, on would be
&#92;x05&#92;x01&#92;x18&#92;x02&#92;x1F. ?A3 is for the "power state at Cold Start"
setting, which I assume means whether it turns back on after power
loss.

On Tue, Feb 15, 2011 at 1:36 PM, cyberbri24 <cyberbri24@> wrote:

Have the 232 ran to my Pro. Pins 2-3, 3-2, and 5-5. Not responding to the data from the protocol manual (I've added to the files docs page). I am sending "0x050x010xA30x010xA5" for Power On but no response. Anyone work this model? Phillips BDL4635 LCD monitor.
Thanks.



------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the Database area.
Yahoo! Groups Links

--
Jeremy Weatherford

------------------------------------



Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the Database area.
Yahoo! Groups Links

--
Jeremy Weatherford

That first should not perform a find before moving to the gather, it should
just loop forever.

<Using GATHER>

WHILE(1)
{
TempString$=GATHER(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......


FIND is expensive, and REMOVE and GATHER are already doing a find - you
don't need to do it twice. You may be able to rewrite your other routine to
remove the 2nd find, but it's not as easy.

An important thing to note about GATHER, is that it will only search through
the new data that comes in, significantly speeding things along. So, if
you've got a pile of data in the buffer that GATHER has already gone
through, *it will not go through it again* looking for the delimiter, but
will only look through the new data. (I found this out by once trying to
trip the GATHER by putting a delimiter at the front of a buffer that it
already searched through, but it would never find it.)

So, looking at the GATHER code, it's only searching through the new data for
your delimiter, then pulling out the substring when it finds it. In the
REMOVE code, you first search through the buffer starting at *the
beginning* looking
for the delimiter to satisfy the WHILE(FIND..), then *again* search through
the buffer *from the beginning* when you do the REMOVE to pull out the temp
string.

Say you're looking for a 1 in a string of 0's coming in.

in -> *0000000*

FIND/REMOVE
(2 searches through all 7 positions - 14 comparisons - no dice).
GATHER
(1 search through all 7 positions - 7 comparisons - no dice).

in -> 0000000*001*
*
*
FIND/REMOVE
(2 searched through all 10 positions - 20 comparisons - oh, there it is)
GATHER
(1 search through the most recent data - 3 comparisons - oh, there it is)

They both function, but the GATHER did 10 total comparisons, while the
FIND/REMOVE did 34, which can translate to a big difference in performance.
Also you didn't have to play with reentrancy issues, think about memory
requirements for each new thread, etc.

Ian Epperson


On Tue, Feb 15, 2011 at 12:10 PM, Stig <stig.karlsen@...> wrote:

I was reffering to their similarity in result when continous extracting
data to a tempstring from large serial buffer with constant traffic.

i.e a CHANGE event from a videoconference-device has a delimiter on each
line of information "&#92;x0D&#92;x0A"(CRLF) in the datastructure.

<Using GATHER>

WHILE(FIND(CRLF,Device_rx$)>0)
{
TempString$=GATHER(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......

<Using REMOVE>

WHILE(FIND(CRLF,Device_rx$)>0)
{
TempString$=REMOVE(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......

Both techniques seems to work equal, but is there a preferred way "Best
practice" here ?

-Stig

--- In Crestron@..., "h2oskr2001" <h2oskr2001@> wrote:

I look at them is as part of techniques / event structures to process

incoming data, e.g. PUSH/gather(), CHANGE/remove().

I use CHANGE/remove when the frequency of input is relatively low and/or

I expect the whole string I care about to arrive within 1 or 2 CHANGE
events. The general behavior is that you get signaled with a CHANGE when
something gets added to the buffer and then use the remove() to see if what
you are looking for is there. If not, exit the event. You incur the task
startup overhead on each CHANGE and the same event can occur while you're
processing one (need re-entrancy protection). If the incoming data rate is
high enough and you spend a lot of time processing in 1 event, you can
experience a number of issues that stem from the system spending more time
creating CHANGE tasks than you spend in processing and getting out.

I use a PUSH/gather() when connected to a device that is going to be

sending info relatively frequently or I want to minimize the overhead when
data does come in. The general behavior is that a task, PUSH or MAIN, is
already running and you call gather() which blocks until the the condition
is met (or it times out). After processing you call the gather() again.
There is only ever 1 task running for the activity and there is no
additional task startup overhead.

HTH,
Dave

--- In Crestron@..., "Stig" <stig.karlsen@> wrote:

I have with great interest following the ongoing "GATHER" thread, and I

am wondering if there is a best practice for using GATHER versus REMOVE ?

Up until now I have only used REMOVE, and out of curiosity i made a

comparison today with two exact modules. One with GATHER and the other with
REMOVE. I could not see any timeleaps(timedifferences) between them. I
swapped place (order) in simple and still they appeared to parse at the same
speed.

Any experiences ?

-Stig

------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

--
This email is intended for the use of the individual addressee(s) named
above and may contain information that is confidential, privileged or
unsuitable for overly sensitive persons with low self-esteem, no sense of
humor or irrational religious beliefs. If you are not the intended
recipient, any dissemination, distribution or copying of this email is not
authorized (either explicitly or implicitly) and constitutes an irritating
social faux pas. Unless the word absquatulation has been used in its correct
context somewhere other than in this warning, it does not have any legal or
grammatical use and may be ignored. No animals were harmed in the
transmission of this email, although the yorkshire terrier next door is
living on borrowed time, let me tell you. Those of you with an overwhelming
fear of the unknown will be gratified to learn that there is no hidden
message revealed by reading this warning backwards, so just ignore that
Alert Notice from Microsoft: However, by pouring a complete circle of salt
around yourself and your computer you can ensure that no harm befalls you
and your pets. If you have received this email in error, please add some
nutmeg and egg whites and place it in a warm oven for 40 minutes. Whisk
briefly and let it stand for 2 hours before icing.

That first should not perform a find before moving to the gather, it should
just loop forever.

<Using GATHER>

WHILE(1)
{
TempString$=GATHER(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......


FIND is expensive, and REMOVE and GATHER are already doing a find - you
don't need to do it twice. You may be able to rewrite your other routine to
remove the 2nd find, but it's not as easy.

An important thing to note about GATHER, is that it will only search through
the new data that comes in, significantly speeding things along. So, if
you've got a pile of data in the buffer that GATHER has already gone
through, *it will not go through it again* looking for the delimiter, but
will only look through the new data. (I found this out by once trying to
trip the GATHER by putting a delimiter at the front of a buffer that it
already searched through, but it would never find it.)

So, looking at the GATHER code, it's only searching through the new data for
your delimiter, then pulling out the substring when it finds it. In the
REMOVE code, you first search through the buffer starting at *the
beginning* looking
for the delimiter to satisfy the WHILE(FIND..), then *again* search through
the buffer *from the beginning* when you do the REMOVE to pull out the temp
string.

Say you're looking for a 1 in a string of 0's coming in.

in -> *0000000*

FIND/REMOVE
(2 searches through all 7 positions - 14 comparisons - no dice).
GATHER
(1 search through all 7 positions - 7 comparisons - no dice).

in -> 0000000*001*
*
*
FIND/REMOVE
(2 searched through all 10 positions - 20 comparisons - oh, there it is)
GATHER
(1 search through the most recent data - 3 comparisons - oh, there it is)

They both function, but the GATHER did 10 total comparisons, while the
FIND/REMOVE did 34, which can translate to a big difference in performance.
Also you didn't have to play with reentrancy issues, think about memory
requirements for each new thread, etc.

Ian Epperson


On Tue, Feb 15, 2011 at 12:10 PM, Stig <stig.karlsen@...> wrote:

I was reffering to their similarity in result when continous extracting
data to a tempstring from large serial buffer with constant traffic.

i.e a CHANGE event from a videoconference-device has a delimiter on each
line of information "&#92;x0D&#92;x0A"(CRLF) in the datastructure.

<Using GATHER>

WHILE(FIND(CRLF,Device_rx$)>0)
{
TempString$=GATHER(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......

<Using REMOVE>

WHILE(FIND(CRLF,Device_rx$)>0)
{
TempString$=REMOVE(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......

Both techniques seems to work equal, but is there a preferred way "Best
practice" here ?

-Stig

--- In Crestron@..., "h2oskr2001" <h2oskr2001@> wrote:

I look at them is as part of techniques / event structures to process

incoming data, e.g. PUSH/gather(), CHANGE/remove().

I use CHANGE/remove when the frequency of input is relatively low and/or

I expect the whole string I care about to arrive within 1 or 2 CHANGE
events. The general behavior is that you get signaled with a CHANGE when
something gets added to the buffer and then use the remove() to see if what
you are looking for is there. If not, exit the event. You incur the task
startup overhead on each CHANGE and the same event can occur while you're
processing one (need re-entrancy protection). If the incoming data rate is
high enough and you spend a lot of time processing in 1 event, you can
experience a number of issues that stem from the system spending more time
creating CHANGE tasks than you spend in processing and getting out.

I use a PUSH/gather() when connected to a device that is going to be

sending info relatively frequently or I want to minimize the overhead when
data does come in. The general behavior is that a task, PUSH or MAIN, is
already running and you call gather() which blocks until the the condition
is met (or it times out). After processing you call the gather() again.
There is only ever 1 task running for the activity and there is no
additional task startup overhead.

HTH,
Dave

--- In Crestron@..., "Stig" <stig.karlsen@> wrote:

I have with great interest following the ongoing "GATHER" thread, and I

am wondering if there is a best practice for using GATHER versus REMOVE ?

Up until now I have only used REMOVE, and out of curiosity i made a

comparison today with two exact modules. One with GATHER and the other with
REMOVE. I could not see any timeleaps(timedifferences) between them. I
swapped place (order) in simple and still they appeared to parse at the same
speed.

Any experiences ?

-Stig

------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

--
This email is intended for the use of the individual addressee(s) named
above and may contain information that is confidential, privileged or
unsuitable for overly sensitive persons with low self-esteem, no sense of
humor or irrational religious beliefs. If you are not the intended
recipient, any dissemination, distribution or copying of this email is not
authorized (either explicitly or implicitly) and constitutes an irritating
social faux pas. Unless the word absquatulation has been used in its correct
context somewhere other than in this warning, it does not have any legal or
grammatical use and may be ignored. No animals were harmed in the
transmission of this email, although the yorkshire terrier next door is
living on borrowed time, let me tell you. Those of you with an overwhelming
fear of the unknown will be gratified to learn that there is no hidden
message revealed by reading this warning backwards, so just ignore that
Alert Notice from Microsoft: However, by pouring a complete circle of salt
around yourself and your computer you can ensure that no harm befalls you
and your pets. If you have received this email in error, please add some
nutmeg and egg whites and place it in a warm oven for 40 minutes. Whisk
briefly and let it stand for 2 hours before icing.

Hi,

I have just posted a file in the module directory that converts Fahrenheit to Celsius. It is based on serial strings but it explain the math.

-Stig

--- In Crestron@..., "neil.dorin" <neildorin@> wrote:

So, as part of the new software release yesterday, the Crestron Weather Device is now available and operational (After I spent a day two weeks ago updating and customizing the old Yahoo Direct Socket module...).

Anyway, I'm testing it out on my home system today and discovered an interesting glitch. When displaying temperatures in Celcius (I imagine this would also occur in Fahrenheit but you'd have to have temps below 0?F) and negative values output as serial text are displayed as negative subtracted analogs (i.e. -5?C is displayed as -65530?C, or 0 - 5).

There's two modules, one is the Crestron Weather Processor v1.2 (cm) and the other is the Crestron Weather Touchpanel Interface v1.0 (cm).

The Processor v1.2 module has analog outputs for temp values that display as the same negative value (-65530d) in debugger, but if I right click on the signal and set the display format to signed decimal, then it corrects to -5d.

I haven't opened them up in SIMPL to have a look at what's going on yet (I imagine this is a S+ issue), but does anyone have an obvious clue as to the error or how to correct it?

I'm sending a bug report to TB too.

Thanks,

-Neil

I was reffering to their similarity in result when continous extracting
data to a tempstring from large serial buffer with constant traffic.

i.e a CHANGE event from a videoconference-device has a delimiter on each
line of information "&#92;x0D&#92;x0A"(CRLF) in the datastructure.

<Using GATHER>

WHILE(FIND(CRLF,Device_rx$)>0)
{
TempString$=GATHER(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......

<Using REMOVE>

WHILE(FIND(CRLF,Device_rx$)>0)
{
TempString$=REMOVE(CRLF,Device_rx$);
IF(FIND(STRING,TempString)>0)
{
STARTINTEGER=FIND( and so on......

Both techniques seems to work equal, but is there a preferred way "Best
practice" here ?

-Stig

--- In Crestron@..., "h2oskr2001" <h2oskr2001@...> wrote:

I look at them is as part of techniques / event structures to process

incoming data, e.g. PUSH/gather(), CHANGE/remove().

I use CHANGE/remove when the frequency of input is relatively low and/or

I expect the whole string I care about to arrive within 1 or 2 CHANGE
events. The general behavior is that you get signaled with a CHANGE when
something gets added to the buffer and then use the remove() to see if what
you are looking for is there. If not, exit the event. You incur the task
startup overhead on each CHANGE and the same event can occur while you're
processing one (need re-entrancy protection). If the incoming data rate is
high enough and you spend a lot of time processing in 1 event, you can
experience a number of issues that stem from the system spending more time
creating CHANGE tasks than you spend in processing and getting out.

I use a PUSH/gather() when connected to a device that is going to be

sending info relatively frequently or I want to minimize the overhead when
data does come in. The general behavior is that a task, PUSH or MAIN, is
already running and you call gather() which blocks until the the condition
is met (or it times out). After processing you call the gather() again.
There is only ever 1 task running for the activity and there is no
additional task startup overhead.

HTH,
Dave

--- In Crestron@..., "Stig" <stig.karlsen@> wrote:

I have with great interest following the ongoing "GATHER" thread, and I

am wondering if there is a best practice for using GATHER versus REMOVE ?

Up until now I have only used REMOVE, and out of curiosity i made a

comparison today with two exact modules. One with GATHER and the other with
REMOVE. I could not see any timeleaps(timedifferences) between them. I
swapped place (order) in simple and still they appeared to parse at the same
speed.

Any experiences ?

-Stig

------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

Don't think it's an issue with Simpl+... I had a similar issue working with Modbus strings not using Simpl+. Modbus would show -5 and I would get a -65530 or something. It was like I was getting the inverse of what I was expecting (minus the whole negative sign thing).

I think the problem has more to do with how analogs are treated but I could be (and most times are) wrong.

JRW

--- In Crestron@..., "neil.dorin" <neildorin@> wrote:

So, as part of the new software release yesterday, the Crestron Weather Device is now available and operational (After I spent a day two weeks ago updating and customizing the old Yahoo Direct Socket module...).

Anyway, I'm testing it out on my home system today and discovered an interesting glitch. When displaying temperatures in Celcius (I imagine this would also occur in Fahrenheit but you'd have to have temps below 0?F) and negative values output as serial text are displayed as negative subtracted analogs (i.e. -5?C is displayed as -65530?C, or 0 - 5).

There's two modules, one is the Crestron Weather Processor v1.2 (cm) and the other is the Crestron Weather Touchpanel Interface v1.0 (cm).

The Processor v1.2 module has analog outputs for temp values that display as the same negative value (-65530d) in debugger, but if I right click on the signal and set the display format to signed decimal, then it corrects to -5d.

I haven't opened them up in SIMPL to have a look at what's going on yet (I imagine this is a S+ issue), but does anyone have an obvious clue as to the error or how to correct it?

I'm sending a bug report to TB too.

Thanks,

-Neil

So, as part of the new software release yesterday, the Crestron Weather Device is now available and operational (After I spent a day two weeks ago updating and customizing the old Yahoo Direct Socket module...).

Anyway, I'm testing it out on my home system today and discovered an interesting glitch. When displaying temperatures in Celcius (I imagine this would also occur in Fahrenheit but you'd have to have temps below 0?F) and negative values output as serial text are displayed as negative subtracted analogs (i.e. -5?C is displayed as -65530?C, or 0 - 5).

There's two modules, one is the Crestron Weather Processor v1.2 (cm) and the other is the Crestron Weather Touchpanel Interface v1.0 (cm).

The Processor v1.2 module has analog outputs for temp values that display as the same negative value (-65530d) in debugger, but if I right click on the signal and set the display format to signed decimal, then it corrects to -5d.

I haven't opened them up in SIMPL to have a look at what's going on yet (I imagine this is a S+ issue), but does anyone have an obvious clue as to the error or how to correct it?

I'm sending a bug report to TB too.

Thanks,

-Neil

I uploaded an update at www.rickmcneely.com/files. It is named HTWin_1.9.0.5.

Let me know if it helps.

Rick


--- In Crestron@..., "rickmcneely" <rickmcneely@> wrote:

goto www.rickmcneely.com/files and try HTWin_1.0.9.5.zip. Lemme know how that works.

Thanks for the feedback.

Rick


--- In Crestron@..., Eric Walters <sentry07@> wrote:

I have two types of errors in the event viewer for HTWin. I believe the
OLEAUT32.dll is the one dealing with the Belkin hardware.

Faulting application name: HTWin.exe, version: 1.0.8.280, time stamp:
0x00003039
Faulting module name: ntdll.dll, version: 6.1.7600.16385, time stamp:
0x4a5bdadb
Exception code: 0xc0000005
Fault offset: 0x0005205b
Faulting process id: 0x1854
Faulting application start time: 0x01cbbdb181fa32b0
Faulting appliecation path: C:&#92;HTWin&#92;HTWin.exe
Faulting module path: C:&#92;Windows&#92;SYSTEM32&#92;ntdll.dll
Report Id: adcfe320-29a5-11e0-987f-60fb4284da83

Faulting application name: HTWin.exe, version: 1.0.8.280, time stamp:
0x00003039
Faulting module name: OLEAUT32.DLL, version: 6.1.7600.16385, time stamp:
0x4a5bdaca
Exception code: 0xc0000005
Fault offset: 0x00003e8d
Faulting process id: 0x19b8
Faulting application start time: 0x01cbbdb3b1941a20
Faulting application path: C:&#92;HTWin&#92;HTWin.exe
Faulting module path: C:&#92;Windows&#92;system32&#92;OLEAUT32.DLL
Report Id: 017de520-29a7-11e0-987f-60fb4284da83

On Mon, Feb 14, 2011 at 6:30 AM, Rick McNeely <rickmcneely@> wrote:

Thanks Jeff,

My Belkin is on it's way. I'll let you know what I find.


[Non-text portions of this message have been removed]



------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

[Non-text portions of this message have been removed]

goto www.rickmcneely.com/files and try HTWin_1.0.9.5.zip. Lemme know how that works.

goto www.rickmcneely.com/files and try HTWin_1.0.9.5.zip. Lemme know how that works.

Thanks for the feedback.

Rick


--- In Crestron@..., Eric Walters <sentry07@> wrote:

I have two types of errors in the event viewer for HTWin. I believe the
OLEAUT32.dll is the one dealing with the Belkin hardware.

Faulting application name: HTWin.exe, version: 1.0.8.280, time stamp:
0x00003039
Faulting module name: ntdll.dll, version: 6.1.7600.16385, time stamp:
0x4a5bdadb
Exception code: 0xc0000005
Fault offset: 0x0005205b
Faulting process id: 0x1854
Faulting application start time: 0x01cbbdb181fa32b0
Faulting appliecation path: C:&#92;HTWin&#92;HTWin.exe
Faulting module path: C:&#92;Windows&#92;SYSTEM32&#92;ntdll.dll
Report Id: adcfe320-29a5-11e0-987f-60fb4284da83

Faulting application name: HTWin.exe, version: 1.0.8.280, time stamp:
0x00003039
Faulting module name: OLEAUT32.DLL, version: 6.1.7600.16385, time stamp:
0x4a5bdaca
Exception code: 0xc0000005
Fault offset: 0x00003e8d
Faulting process id: 0x19b8
Faulting application start time: 0x01cbbdb3b1941a20
Faulting application path: C:&#92;HTWin&#92;HTWin.exe
Faulting module path: C:&#92;Windows&#92;system32&#92;OLEAUT32.DLL
Report Id: 017de520-29a7-11e0-987f-60fb4284da83

On Mon, Feb 14, 2011 at 6:30 AM, Rick McNeely <rickmcneely@> wrote:

Thanks Jeff,

My Belkin is on it's way. I'll let you know what I find.


[Non-text portions of this message have been removed]



------------------------------------




Check out the Files area for useful modules, documents, and drivers.

A contact list of Crestron dealers and programmers can be found in the
Database area.
Yahoo!
Groups Links

[Non-text portions of this message have been removed]

So, as part of the new software release yesterday, the Crestron Weather Device is now available and operational (After I spent a day two weeks ago updating and customizing the old Yahoo Direct Socket module...).

Anyway, I'm testing it out on my home system today and discovered an interesting glitch. When displaying temperatures in Celcius (I imagine this would also occur in Fahrenheit but you'd have to have temps below 0?F) and negative values output as serial text are displayed as negative subtracted analogs (i.e. -5?C is displayed as -65530?C, or 0 - 5).

There's two modules, one is the Crestron Weather Processor v1.2 (cm) and the other is the Crestron Weather Touchpanel Interface v1.0 (cm).

The Processor v1.2 module has analog outputs for temp values that display as the same negative value (-65530d) in debugger, but if I right click on the signal and set the display format to signed decimal, then it corrects to -5d.

I haven't opened them up in SIMPL to have a look at what's going on yet (I imagine this is a S+ issue), but does anyone have an obvious clue as to the error or how to correct it?

I'm sending a bug report to TB too.

Thanks,

-Neil

Issues with new SIMPL v3.01.22.00. loaded 2 programs today that were fine
before installing new SIMPL

That now whack out the processor after loading. Watching processor shut off
and on. Cannot reconnect

To it. shows no program loaded. Going back to previous version of SIMPL.



Chris Armbrust

Tempus Electronic Lifestyles

Director of Engineering, Sr. Programmer

941-316-8812 office

941-238-8471 cell

I look at them is as part of techniques / event structures to process incoming data, e.g. PUSH/gather(), CHANGE/remove().

I use CHANGE/remove when the frequency of input is relatively low and/or I expect the whole string I care about to arrive within 1 or 2 CHANGE events. The general behavior is that you get signaled with a CHANGE when something gets added to the buffer and then use the remove() to see if what you are looking for is there. If not, exit the event. You incur the task startup overhead on each CHANGE and the same event can occur while you're processing one (need re-entrancy protection). If the incoming data rate is high enough and you spend a lot of time processing in 1 event, you can experience a number of issues that stem from the system spending more time creating CHANGE tasks than you spend in processing and getting out.

I use a PUSH/gather() when connected to a device that is going to be sending info relatively frequently or I want to minimize the overhead when data does come in. The general behavior is that a task, PUSH or MAIN, is already running and you call gather() which blocks until the the condition is met (or it times out). After processing you call the gather() again. There is only ever 1 task running for the activity and there is no additional task startup overhead.

HTH,
Dave

--- In Crestron@..., "Stig" <stig.karlsen@> wrote:

I have with great interest following the ongoing "GATHER" thread, and I am wondering if there is a best practice for using GATHER versus REMOVE ?

Up until now I have only used REMOVE, and out of curiosity i made a comparison today with two exact modules. One with GATHER and the other with REMOVE. I could not see any timeleaps(timedifferences) between them. I swapped place (order) in simple and still they appeared to parse at the same speed.
Any experiences ?

-Stig