开云体育

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a >lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a >lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle <crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a >lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

Do you have full feedback from the displays?

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

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle <crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a >lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle<crestron@...> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

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



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

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide unsolicited
feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle<crestron@...> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

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



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

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



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

You know, this really gets at programming technique which is something Crestron has always stayed out of. They offer best practices for specific situations sometimes, but overall architecture is absent. So like most programmers with experience, I have my own approach I use over and over. There are a lot of unpaid hours that went into it, but that time is recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most part and begin thinking in terms of logic wave pulses and wave delays where that sort of thing is needed. I know I spend an unhealthy amount of time tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a standard architecture for program design, something like an open source project. In my mind the focus would be creating an overall architecture with cut-and-paste-ready logic modules with well defined standard interfaces. There are a lot of device modules in the files section, but I haven't seen a lot other than that, and there is no standardization at all really.

Maybe most of you have too much invested in your own approaches to want to share techniques, even I'm not sure I want to do that, but it won't hurt to discuss it.

Sorry to hijack the thread.

Barry



On Apr 12, 2012, at 6:54 PM, Steve Kaudle wrote:

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide unsolicited
feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle<crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

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



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

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



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

I just yesterday sat with one of the other programmers here for an hour to try to standardize things here and basically got nowhere, and we're just three programmers. It drives the owner nuts, but we're programmers and almost if it goes hand in hand, have egos. I once worked at a company for just two weeks: Try telling someone who's been programming for 12 years (self taught, not a single class) that there's a better way to do things. Resentment doesn't even begin to describe it. I quit because (among other things) there was no way in hell I was going to go back to buffers after doing crosspoints.

/rant

--- In Crestron@..., Barry Newton <barry@> wrote:

You know, this really gets at programming technique which is something Crestron has always stayed out of. They offer best practices for specific situations sometimes, but overall architecture is absent. So like most programmers with experience, I have my own approach I use over and over. There are a lot of unpaid hours that went into it, but that time is recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most part and begin thinking in terms of logic wave pulses and wave delays where that sort of thing is needed. I know I spend an unhealthy amount of time tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a standard architecture for program design, something like an open source project. In my mind the focus would be creating an overall architecture with cut-and-paste-ready logic modules with well defined standard interfaces. There are a lot of device modules in the files section, but I haven't seen a lot other than that, and there is no standardization at all really.

Maybe most of you have too much invested in your own approaches to want to share techniques, even I'm not sure I want to do that, but it won't hurt to discuss it.

Sorry to hijack the thread.

Barry



On Apr 12, 2012, at 6:54 PM, Steve Kaudle wrote:

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide unsolicited
feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle<crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

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



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

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



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

You know, this really gets at programming technique which is something Crestron has always stayed out of. They offer best practices for specific situations sometimes, but overall architecture is absent. So like most programmers with experience, I have my own approach I use over and over. There are a lot of unpaid hours that went into it, but that time is recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most part and begin thinking in terms of logic wave pulses and wave delays where that sort of thing is needed. I know I spend an unhealthy amount of time tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a standard architecture for program design, something like an open source project. In my mind the focus would be creating an overall architecture with cut-and-paste-ready logic modules with well defined standard interfaces. There are a lot of device modules in the files section, but I haven't seen a lot other than that, and there is no standardization at all really.

Maybe most of you have too much invested in your own approaches to want to share techniques, even I'm not sure I want to do that, but it won't hurt to discuss it.

Sorry to hijack the thread.

Barry



On Apr 12, 2012, at 6:54 PM, Steve Kaudle wrote:

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide unsolicited
feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle<crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

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



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

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



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

So you want to write another systembuilder?

So you want to write another systembuilder?

--- In Crestron@..., Barry Newton <barry@...> wrote:

You know, this really gets at programming technique which is something Crestron has always stayed out of. They offer best practices for specific situations sometimes, but overall architecture is absent. So like most programmers with experience, I have my own approach I use over and over. There are a lot of unpaid hours that went into it, but that time is recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most part and begin thinking in terms of logic wave pulses and wave delays where that sort of thing is needed. I know I spend an unhealthy amount of time tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a standard architecture for program design, something like an open source project. In my mind the focus would be creating an overall architecture with cut-and-paste-ready logic modules with well defined standard interfaces. There are a lot of device modules in the files section, but I haven't seen a lot other than that, and there is no standardization at all really.

Maybe most of you have too much invested in your own approaches to want to share techniques, even I'm not sure I want to do that, but it won't hurt to discuss it.

Sorry to hijack the thread.

Barry



On Apr 12, 2012, at 6:54 PM, Steve Kaudle wrote:

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide unsolicited
feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle<crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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

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



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

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



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

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



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

**


So you want to write another systembuilder?


--- In Crestron@..., Barry Newton <barry@...> wrote:

You know, this really gets at programming technique which is something

Crestron has always stayed out of. They offer best practices for specific
situations sometimes, but overall architecture is absent. So like most
programmers with experience, I have my own approach I use over and over.
There are a lot of unpaid hours that went into it, but that time is
recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most

part and begin thinking in terms of logic wave pulses and wave delays where
that sort of thing is needed. I know I spend an unhealthy amount of time
tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a

standard architecture for program design, something like an open source
project. In my mind the focus would be creating an overall architecture
with cut-and-paste-ready logic modules with well defined standard
interfaces. There are a lot of device modules in the files section, but I
haven't seen a lot other than that, and there is no standardization at all
really.

Maybe most of you have too much invested in your own approaches to want

to share techniques, even I'm not sure I want to do that, but it won't hurt
to discuss it.

Sorry to hijack the thread.

Barry



On Apr 12, 2012, at 6:54 PM, Steve Kaudle wrote:

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide

unsolicited

feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what

source has been selected they both may or may not need to be powered up at
the same time. And here is the kicker, they both have different warm up
times, and the "system is warming up" page needs to be held high during the
power up cycle.

So if A takes 10s to warm up, but has been powered up at the same

time as B (which takes 20s), the warm up page needs to be high for 20s.

--- In Crestron@..., Steve Kaudle<crestron@> wrote:

From a more abstract/best practices standpoint, you should try to

keep

the amount of timed events (steppers, delays, one-shots, etc...) you

use

to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything

like

'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed

events

and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based

on a

specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and

I am always looking at improving and following best practices. Having said
that I have a question.

Is it bad to have 2 or 3 steppers running concurrently? Depending

on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is

triggered, this fires up the proj and sends down the screen, whilst
indicating the system is warming up.

If a different source is selected, it might be destined for other

displays, which in turn will trigger their respective steppers.

So there might be a few steppers running at the same time.




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

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

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

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

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

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

That's a far reaching generalization to call that methodology anything like
systembuilder.

For a long time, I've shared a similar mentality to Barry's whereby it
irritates me to no end how juvenile and immature the AV programming
community as a whole is (I concede that there are obvious exceptions, but
for the case of this argument let's assume I'm right).

If you look at ANY other software industry and compare it to ours, the
contradictions are glaring. Why? Because we tend to cling to the silly
notion that we're "different" because we deal with A/V and archaic
proprietary RS-232 protocols and such....

The reality is that we're no different. We produce computer software. We
write code. We build graphical user interfaces. Guess what? We're not
exactly pioneers here....

I think it was Nathan in the thread about locked code/modules lately that
made a statement that brought a smile to my face and gave me hope. The
world of PC programming discovered years ago that protecting common code
that almost every one of their competitors was using wasn't making them
more competitive or profitable and that it was far more beneficial to
themselves, and the industry as a whole, to share such code amongst each
other. These days, most PC programmers rarely write anything truly
original, instead they use OOP libraries and class modules to adapt for
their purposes. The originality, profitability and ingenuity comes in
combining them in some new and more effective way that advances the
efficiency or capability of the software. It's pretty hard to get to that
point if you have to start from scratch and write everything yourself.
With a solid foundation (i.e. Andriod OS) that is developed and improved in
a open source environment, there is still a TON of room and market to build
innovative profitable products.

I watch my own team of ~10 programmers constantly each spend hours trying
to solve the same problem on their own. While I value each person's
approach and don't really have an opinion on which way is better as long as
the finished product is the same, it's terribly inefficient for the company
and themselves. What AV programmers need to realize is that we would all
make more money and do less work if we behaved more like the rest of the
programming world. Find the common problems and scenarios, solve them
generically, efficiently and in a way that is reusable in as many
situations as possible and instead spend your time and effort on the
problems and scenarios that are uncommon or adding new features that add
value.

</rant...>

That's a far reaching generalization to call that methodology anything like
systembuilder.

For a long time, I've shared a similar mentality to Barry's whereby it
irritates me to no end how juvenile and immature the AV programming
community as a whole is (I concede that there are obvious exceptions, but
for the case of this argument let's assume I'm right).

If you look at ANY other software industry and compare it to ours, the
contradictions are glaring. Why? Because we tend to cling to the silly
notion that we're "different" because we deal with A/V and archaic
proprietary RS-232 protocols and such....

The reality is that we're no different. We produce computer software. We
write code. We build graphical user interfaces. Guess what? We're not
exactly pioneers here....

I think it was Nathan in the thread about locked code/modules lately that
made a statement that brought a smile to my face and gave me hope. The
world of PC programming discovered years ago that protecting common code
that almost every one of their competitors was using wasn't making them
more competitive or profitable and that it was far more beneficial to
themselves, and the industry as a whole, to share such code amongst each
other. These days, most PC programmers rarely write anything truly
original, instead they use OOP libraries and class modules to adapt for
their purposes. The originality, profitability and ingenuity comes in
combining them in some new and more effective way that advances the
efficiency or capability of the software. It's pretty hard to get to that
point if you have to start from scratch and write everything yourself.
With a solid foundation (i.e. Andriod OS) that is developed and improved in
a open source environment, there is still a TON of room and market to build
innovative profitable products.

I watch my own team of ~10 programmers constantly each spend hours trying
to solve the same problem on their own. While I value each person's
approach and don't really have an opinion on which way is better as long as
the finished product is the same, it's terribly inefficient for the company
and themselves. What AV programmers need to realize is that we would all
make more money and do less work if we behaved more like the rest of the
programming world. Find the common problems and scenarios, solve them
generically, efficiently and in a way that is reusable in as many
situations as possible and instead spend your time and effort on the
problems and scenarios that are uncommon or adding new features that add
value.

</rant...>



On Fri, Apr 13, 2012 at 12:20 PM, matt_rasmussen_2000 <mjrtoo@...>wrote:

**


So you want to write another systembuilder?


--- In Crestron@..., Barry Newton <barry@> wrote:

You know, this really gets at programming technique which is something

Crestron has always stayed out of. They offer best practices for specific
situations sometimes, but overall architecture is absent. So like most
programmers with experience, I have my own approach I use over and over.
There are a lot of unpaid hours that went into it, but that time is
recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most

part and begin thinking in terms of logic wave pulses and wave delays where
that sort of thing is needed. I know I spend an unhealthy amount of time
tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a

standard architecture for program design, something like an open source
project. In my mind the focus would be creating an overall architecture
with cut-and-paste-ready logic modules with well defined standard
interfaces. There are a lot of device modules in the files section, but I
haven't seen a lot other than that, and there is no standardization at all
really.

Maybe most of you have too much invested in your own approaches to want

to share techniques, even I'm not sure I want to do that, but it won't hurt
to discuss it.

Sorry to hijack the thread.

Barry



On Apr 12, 2012, at 6:54 PM, Steve Kaudle wrote:

To some extent that's dependent on the display's in question (or more
specifically, the completeness of their control API's). Lets assume
that the displays can either be queried and/or will provide

unsolicited

feedback for the current power state (off, warming, on, or cooling).
Given that, I'd write a module that would always tell me the current
power status, and if either of the display's 'warming_fb' outputs were
high, activate the subpage.

On 4/12/2012 6:32 PM, avsystemdesign wrote:

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what

source has been selected they both may or may not need to be powered up at
the same time. And here is the kicker, they both have different warm up
times, and the "system is warming up" page needs to be held high during the
power up cycle.

So if A takes 10s to warm up, but has been powered up at the same

time as B (which takes 20s), the warm up page needs to be high for 20s.

--- In Crestron@..., Steve Kaudle<crestron@> wrote:

From a more abstract/best practices standpoint, you should try to

keep

the amount of timed events (steppers, delays, one-shots, etc...) you

use

to a minimum. That said, I'd bet you'd need to use a>lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything

like

'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed

events

and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based

on a

specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and

I am always looking at improving and following best practices. Having said
that I have a question.

Is it bad to have 2 or 3 steppers running concurrently? Depending

on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is

triggered, this fires up the proj and sends down the screen, whilst
indicating the system is warming up.

If a different source is selected, it might be destined for other

displays, which in turn will trigger their respective steppers.

So there might be a few steppers running at the same time.




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

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

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

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

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

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

I thought it was commonplace to make modules for repetitive tasks, reusable code blocks is really the only way to do it. So I'm not sure what the question really was. You're all writing code from scratch everytime and not sharing a common module database amongst the programmers? This is not an industry problem, it's an administration problem.

This site is all about sharing modules and programming techniques that seem to work best so I disagree we're immature about it, but people like doing things their own way. The only way to get everyone to do things exactly the same is to use a configuration model like Crestron is trying to do with Systembuilder, and extron has done with global configurator. Maybe once we get an object oriented programming language things can advance to the point I think you're trying to make but for now it's the way it is.

The files section is full of examples of people trying to share common code, I freely share my code blocks with CAIPs we occasionally use because I have setup specific guidelines how our systems need to work, and why make someone do that work when I can just give it to them and save valuable time.

I do think what we do is different, while we work within a specific programming structure, the devices we interface with are all over the board. This is far different than a windows programmer that has specific constraints and guidelines that are always true, we do not have that conveinance of an object library, we always have to do some sort of customization between systems based upon factors external to the OS itself.

my .02 anyway, fwiw.


--- In Crestron@..., Neil Dorin <neildorin@...> wrote:

That's a far reaching generalization to call that methodology anything like
systembuilder.

For a long time, I've shared a similar mentality to Barry's whereby it
irritates me to no end how juvenile and immature the AV programming
community as a whole is (I concede that there are obvious exceptions, but
for the case of this argument let's assume I'm right).

If you look at ANY other software industry and compare it to ours, the
contradictions are glaring. Why? Because we tend to cling to the silly
notion that we're "different" because we deal with A/V and archaic
proprietary RS-232 protocols and such....

The reality is that we're no different. We produce computer software. We
write code. We build graphical user interfaces. Guess what? We're not
exactly pioneers here....

I think it was Nathan in the thread about locked code/modules lately that
made a statement that brought a smile to my face and gave me hope. The
world of PC programming discovered years ago that protecting common code
that almost every one of their competitors was using wasn't making them
more competitive or profitable and that it was far more beneficial to
themselves, and the industry as a whole, to share such code amongst each
other. These days, most PC programmers rarely write anything truly
original, instead they use OOP libraries and class modules to adapt for
their purposes. The originality, profitability and ingenuity comes in
combining them in some new and more effective way that advances the
efficiency or capability of the software. It's pretty hard to get to that
point if you have to start from scratch and write everything yourself.
With a solid foundation (i.e. Andriod OS) that is developed and improved in
a open source environment, there is still a TON of room and market to build
innovative profitable products.

I watch my own team of ~10 programmers constantly each spend hours trying
to solve the same problem on their own. While I value each person's
approach and don't really have an opinion on which way is better as long as
the finished product is the same, it's terribly inefficient for the company
and themselves. What AV programmers need to realize is that we would all
make more money and do less work if we behaved more like the rest of the
programming world. Find the common problems and scenarios, solve them
generically, efficiently and in a way that is reusable in as many
situations as possible and instead spend your time and effort on the
problems and scenarios that are uncommon or adding new features that add
value.

</rant...>



On Fri, Apr 13, 2012 at 12:20 PM, matt_rasmussen_2000 <mjrtoo@...>wrote:

**


So you want to write another systembuilder?


--- In Crestron@..., Barry Newton <barry@> wrote:

You know, this really gets at programming technique which is something

Crestron has always stayed out of. They offer best practices for specific
situations sometimes, but overall architecture is absent. So like most
programmers with experience, I have my own approach I use over and over.
There are a lot of unpaid hours that went into it, but that time is
recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most

part and begin thinking in terms of logic wave pulses and wave delays where
that sort of thing is needed. I know I spend an unhealthy amount of time
tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a

standard architecture for program design, something like an open source
project. In my mind the focus would be creating an overall architecture
with cut-and-paste-ready logic modules with well defined standard
interfaces. There are a lot of device modules in the files section, but I
haven't seen a lot other than that, and there is no standardization at all
really.

Maybe most of you have too much invested in your own approaches to want

to share techniques, even I'm not sure I want to do that, but it won't hurt
to discuss it.

Sorry to hijack the thread.

Barry

Sure, we make modules to use over and again, but our modules plug into our programs in whatever way we design for ourselves. The next level of discipline would be to create and share definitions for these interfaces so we can choose to create modules that would work for anyone who adheres to the interface standard.

No one is asking for everyone to do things exactly the same way, but rather to write logic modules which accept inputs and present outputs in a defined way. You certainly don't need a RAD tool to do that, nor does it require an object oriented language. This sort of approach existed long before OO became fashionable. It begins simply with one programmer proposing an interface and having a discussion with some other programmers about it to see if they can agree on a definition they are willing to adhere to.

I think Neil is right in saying what we do is no different from other programming disciplines except when we decide to be. I try to borrow as much from my former life programming (Pascal, FORTRAN, Java, C, Perl, whatever) as I can to standardize things just for myself (such as using SVN or Git so version source for starters).

I'm interested in pursuing something if anyone else is. Otherwise I'll continue to do it my way, make my own standards for myself, and be happy.

Barry


On Apr 13, 2012, at 4:27 PM, matt_rasmussen_2000 wrote:

I thought it was commonplace to make modules for repetitive tasks, reusable code blocks is really the only way to do it. So I'm not sure what the question really was. You're all writing code from scratch everytime and not sharing a common module database amongst the programmers? This is not an industry problem, it's an administration problem.

This site is all about sharing modules and programming techniques that seem to work best so I disagree we're immature about it, but people like doing things their own way. The only way to get everyone to do things exactly the same is to use a configuration model like Crestron is trying to do with Systembuilder, and extron has done with global configurator. Maybe once we get an object oriented programming language things can advance to the point I think you're trying to make but for now it's the way it is.

The files section is full of examples of people trying to share common code, I freely share my code blocks with CAIPs we occasionally use because I have setup specific guidelines how our systems need to work, and why make someone do that work when I can just give it to them and save valuable time.

I do think what we do is different, while we work within a specific programming structure, the devices we interface with are all over the board. This is far different than a windows programmer that has specific constraints and guidelines that are always true, we do not have that conveinance of an object library, we always have to do some sort of customization between systems based upon factors external to the OS itself.

my .02 anyway, fwiw.


--- In Crestron@..., Neil Dorin <neildorin@> wrote:

That's a far reaching generalization to call that methodology anything like
systembuilder.

For a long time, I've shared a similar mentality to Barry's whereby it
irritates me to no end how juvenile and immature the AV programming
community as a whole is (I concede that there are obvious exceptions, but
for the case of this argument let's assume I'm right).

If you look at ANY other software industry and compare it to ours, the
contradictions are glaring. Why? Because we tend to cling to the silly
notion that we're "different" because we deal with A/V and archaic
proprietary RS-232 protocols and such....

The reality is that we're no different. We produce computer software. We
write code. We build graphical user interfaces. Guess what? We're not
exactly pioneers here....

I think it was Nathan in the thread about locked code/modules lately that
made a statement that brought a smile to my face and gave me hope. The
world of PC programming discovered years ago that protecting common code
that almost every one of their competitors was using wasn't making them
more competitive or profitable and that it was far more beneficial to
themselves, and the industry as a whole, to share such code amongst each
other. These days, most PC programmers rarely write anything truly
original, instead they use OOP libraries and class modules to adapt for
their purposes. The originality, profitability and ingenuity comes in
combining them in some new and more effective way that advances the
efficiency or capability of the software. It's pretty hard to get to that
point if you have to start from scratch and write everything yourself.
With a solid foundation (i.e. Andriod OS) that is developed and improved in
a open source environment, there is still a TON of room and market to build
innovative profitable products.

I watch my own team of ~10 programmers constantly each spend hours trying
to solve the same problem on their own. While I value each person's
approach and don't really have an opinion on which way is better as long as
the finished product is the same, it's terribly inefficient for the company
and themselves. What AV programmers need to realize is that we would all
make more money and do less work if we behaved more like the rest of the
programming world. Find the common problems and scenarios, solve them
generically, efficiently and in a way that is reusable in as many
situations as possible and instead spend your time and effort on the
problems and scenarios that are uncommon or adding new features that add
value.

</rant...>



On Fri, Apr 13, 2012 at 12:20 PM, matt_rasmussen_2000 <mjrtoo@>wrote:

**


So you want to write another systembuilder?


--- In Crestron@..., Barry Newton <barry@> wrote:

You know, this really gets at programming technique which is something

Crestron has always stayed out of. They offer best practices for specific
situations sometimes, but overall architecture is absent. So like most
programmers with experience, I have my own approach I use over and over.
There are a lot of unpaid hours that went into it, but that time is
recovered in being able to produce finished programs more quickly.

I suspect most programmers eventually abandon timed logic for the most

part and begin thinking in terms of logic wave pulses and wave delays where
that sort of thing is needed. I know I spend an unhealthy amount of time
tweaking logic just to reduce the number of symbols.

I have wondered if there is interest in the community in creating a

standard architecture for program design, something like an open source
project. In my mind the focus would be creating an overall architecture
with cut-and-paste-ready logic modules with well defined standard
interfaces. There are a lot of device modules in the files section, but I
haven't seen a lot other than that, and there is no standardization at all
really.

Maybe most of you have too much invested in your own approaches to want

to share techniques, even I'm not sure I want to do that, but it won't hurt
to discuss it.

Sorry to hijack the thread.

Barry

Thanks Steve,

Then how would a person create the following condition?

Display A + B can be powered up separately, but depending on what source has been selected they both may or may not need to be powered up at the same time. And here is the kicker, they both have different warm up times, and the "system is warming up" page needs to be held high during the power up cycle.
So if A takes 10s to warm up, but has been powered up at the same time as B (which takes 20s), the warm up page needs to be high for 20s.


--- In Crestron@..., Steve Kaudle <crestron@> wrote:

From a more abstract/best practices standpoint, you should try to keep
the amount of timed events (steppers, delays, one-shots, etc...) you use
to a minimum. That said, I'd bet you'd need to use a >lot< of steppers
before the burden they put on system would be perceived by the
operator. Lots of variables at play and the real world threshold will
likely vary (greatly) from system to system. Note that the previous
statement(s) should most defiantly not be translated into anything like
'stop using timed events if you want your systems to work right'.

From a logical/program flow standpoint, I prefer to avoid timed events
and build logic that is condition dependent. Example: I don't
necessarily want to send an input swap command to a projector based on a
specific amount of time having passed, but rather based on real-time
conditions like the (actual) power state and current input selection.

On 4/12/2012 5:56 PM, avsystemdesign wrote:

I know there are several ways to skin a cat in Crestron world, and I am always looking at improving and following best practices. Having said that I have a question.
Is it bad to have 2 or 3 steppers running concurrently? Depending on the device being used, I like to have a stepper handle the procedure.

For example, source is selected, stepper for projector 1 is triggered, this fires up the proj and sends down the screen, whilst indicating the system is warming up.
If a different source is selected, it might be destined for other displays, which in turn will trigger their respective steppers.
So there might be a few steppers running at the same time.




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



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