Re: Simple + Guru Question - Differences for IP modules between 2 and 3 series
I was told in the last masters the smallest timeslice in 3 series is .000000000001s rather than the .01s in 2 series. Is that not true?
toggle quoted message
Show quoted text
--- In Crestron@..., "RobK" <fooguy89@...> wrote: A "tick" (i.e. 1d in a time based symbol) is 0.01s in terms of crestron programming. That's the same for both 3 series and 2 series.
Gates run faster on the MC3 than they do on the 2 series, but I'm not sure if that's going to really get in your way. Most pure SIMPL solutions work the same. There have been some SIMPL+ gotchas since it's a new platform, but they have endeavored to make most of it the same (and if you do have access to the labs, you CAN post a message to them saying that XXX works on a 2 but not on a 3 series).
But there never was a "time" for a logic wave, anyway, since a "wave" is variable to begin with.
--- In Crestron@..., stranded <strandedyahoo@> wrote:
Is the module completely Simpl+? Having not used a MC3 yet all I can tell you is that if you are using anything that uses ticks for timing it will cause timing issues. This is because a tick in the MC3 is much much shorter than in a 2 series.
On Fri, Apr 13, 2012 at 10:29 AM, waltonad0283 <waltonad0283@>wrote:
**
Hi All,
I have a Simpl+ module that I wrote for an IP controlled device, it works fine with my Cp2E processor in the office. - However - when It got sent out to a client site that has an MC3 in it - it doesn't work.
I am trying to switch audio/video sources - on my Cp2E - everything happens fine. On the MC3, toolbox shows making a successful socket connection, but the switch never happens. Then the socket closes like it's supposed to.. Has anyone else had this happen - on any IP module that worked on a 2 series and not on a 3 series - and if so what was the resolution?
Thanks
[Non-text portions of this message have been removed]
|
Anyone happen to have an extra enclosure for the CNPCI-8 (aka CLCI-8)
Before I go and half-ass something... got a CNPCI-8/CLCI-8 from a project having lighting control upgraded
The system it was in had a CLC-6 which doesn't work for my intended application. Before I either try welding something together (bad idea) or find a not-quite-right-size NEMA enclosure (not as bad but still a bad idea) I figured I'd see if someone might have one kicking around that they'd like to get off their shelf...
Off list at lincoln /at/ controlworks /dot/ com, please and thank you.
Lincoln
|
I'm going to go ahead and say in this day and age if you have 5 ir ports on a box and you can't fire them independently it's an issue.
The note about this has been added to the MC3 FAQ on the TB site.
toggle quoted message
Show quoted text
--- In Crestron@..., "RobK" <fooguy89@...> wrote: I'm not sure I'd call it an "issue" in terms of the original phrasing. The MC3/PMC3/PMC3-XP has one IR generator that is multiplexed amongst the 5 ports. If you turn port 2 while Port 1 is generating, Port 1 will finish the min # of repeats for the given IR command Port 1 is generating, then it will start generating Port 2.
--- In Crestron@..., Steve Kaudle <crestron@> wrote:
As I understand it, if you try to send two IR commands at the same time (not sure if that means an overlapping time duration of the associated digitals, logic wave, or logic solution), one or more of the IR commands will be generated as a single, minimum pulse.
On 4/12/2012 8:50 PM, Witmarquzot wrote:
From what we saw on this group i believe it would stopped if you tried to use two ports at once i think?
It is not labeled as an easy search (MC3 Problems, MC3 Feedback, MC3 IR). Must have been January/Febuary, might have been November
--- In Crestron@..., "floyd1212"<floyd1212@> wrote:
What's the problem with simultaneous IR on the MC3?
--- In Crestron@..., "Witmarquzot"<tdurrant420@> wrote:
Still vapor ware at this point, so who knows
--- In Crestron@..., "John"<ComeAlive@> wrote:
Does the CP3 have the same issue as the MC3 with regards to simultaneous IR output
------------------------------------
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
|
Re: PMC2 not recognized on Tool Box
USB devices don't show up in device discovery tool and it probably has a static IP that's not in the same subnet as the network you're connecting it to. Try connecting via usb and using system info or the new EC (easy connect) tool and specifying USB as the connection method. On Fri, Apr 13, 2012 at 2:11 PM, gsusmood <audioandnetartist@...>wrote: **
Well, just got a PMC2 from a customer that was in the office and I decided to take it home and see what happens to, I hook up via USB Hit Device discovery Tool, nothing came on, Unplug USB connected to router, hit Discovery Tool, nothing came on, When to the App Fing to check Ip's on the network and only my phone, router and PC were available, no PMC2, anyway I can Reboot this and bring it to life?
Thanks on advice!!
[Non-text portions of this message have been removed]
|
Re: OT: Polycom HDX8000 w/BSS AEC but using analog dialer in the HDX8000 question
Thanks Raphael, we are investigating that very question, it's the only thing I can come up with since the video conference audio is just fine.
Appreciate the reply!
toggle quoted message
Show quoted text
--- In Crestron@..., "Raph Paf" <raphael.thiffault@...> wrote: It's a real analog line or a module who convert an ip extension into an analog extension. i have seen this in the past and it was cause by the device who create the analog line.
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@> wrote:
For some reason I've been assigned the task of figuring out this issue and wondering if someone here can help out real quick.
An older Vortex system was replaced with BSS and a new HDX8000, but the engineer didn't understand that the old EF2241 had an analog phone dialer and didn't include one in the BSS (used the BLU-101 instead of the 102). So, they are using the analog phone input of the HDX8000 to dial those calls. As far as programming goes, it's working fine, but it appears that the analog phone calls are half-duplex, so if someone is talking in the local room, or, an audio source is playing, the far site on the phone call cannot be heard or interrupt the local conversation. The video conference audio is just fine, full duplex communication etc. The BSS is currently setup to do the AEC processing in the system and the AEC is off in the codec.
I guess I don't understand why the analog phone would be any different than the video conference audio coming out of the codec and processed by the BSS? I've looked through the menus of the codec to look for any settings for the analog dialer, but I can't see anything that would set it up for half duplex. Or, maybe the dialer in the HDX8000 is just half-duplex?
|
Re: Simple + Guru Question - Differences for IP modules between 2 and 3 series
A "tick" (i.e. 1d in a time based symbol) is 0.01s in terms of crestron programming. That's the same for both 3 series and 2 series.
Gates run faster on the MC3 than they do on the 2 series, but I'm not sure if that's going to really get in your way. Most pure SIMPL solutions work the same. There have been some SIMPL+ gotchas since it's a new platform, but they have endeavored to make most of it the same (and if you do have access to the labs, you CAN post a message to them saying that XXX works on a 2 but not on a 3 series).
But there never was a "time" for a logic wave, anyway, since a "wave" is variable to begin with.
toggle quoted message
Show quoted text
--- In Crestron@..., stranded <strandedyahoo@...> wrote: Is the module completely Simpl+? Having not used a MC3 yet all I can tell you is that if you are using anything that uses ticks for timing it will cause timing issues. This is because a tick in the MC3 is much much shorter than in a 2 series.
On Fri, Apr 13, 2012 at 10:29 AM, waltonad0283 <waltonad0283@...>wrote:
**
Hi All,
I have a Simpl+ module that I wrote for an IP controlled device, it works fine with my Cp2E processor in the office. - However - when It got sent out to a client site that has an MC3 in it - it doesn't work.
I am trying to switch audio/video sources - on my Cp2E - everything happens fine. On the MC3, toolbox shows making a successful socket connection, but the switch never happens. Then the socket closes like it's supposed to.. Has anyone else had this happen - on any IP module that worked on a 2 series and not on a 3 series - and if so what was the resolution?
Thanks
[Non-text portions of this message have been removed]
|
Re: Best way to widen my programming ablility
That's great advice, and a great link, Jeremy!
toggle quoted message
Show quoted text
--- On Friday, April 13, 2012 at 2:25 PM, Jeremy Weatherford wrote:
Handy reference here: Teach Yourself Programming in Ten Years:
Specific to Crestron, make sure you get to training classes, as they will teach you things that are difficult to learn on your own. Get your own processor (QM-RMC or DIN-AP2) if you don't already have one to test things on. Get familiar with Debugger, explore existing programs in it and make sure you really understand how they work, and not just what they do. Read the SIMPL Primer and the symbol help files. Make sure you know what all the symbols in the symbol library do -- that will come in handy some day when you're saying "I know there's a symbol that does X..." even if you don't remember exactly what it's called. Many of the more complex symbol help topics also give examples of how you might use them. If you're not sure how something works, write a little test program so you can poke the symbol in Debugger and see what happens.
Learn to read protocol documents... I enjoy when people post questions about protocols on this group, because, time permitting, I try to decipher the protocol myself, whether or not I can answer their actual question. The more protocol documents I decipher, the easier it is to interpret new protocols.
Identify your weak spots and start practicing with them. Crosspoints? SIMPL+? Serial parsing in SIMPL? Analog logic? Modules? Hex/ASCII/decimal data formats? Page flip logic? What are some things that you might be asked to add to a program that would be useful to practice beforehand? Timeserver synchronization? XPanels? iPads? Lamp hours? Countdown timer for a presenter? Weather/news/stock tickers?
There's no substitute for practice... to make it more realistic, be sure you sit on a 5-gallon bucket in an active sawmill and give yourself a deadline of 15 minutes until the CEO's presentation starts.
On Fri, Apr 13, 2012 at 1:48 PM, coreygsimpson <coreygsimpson@...> wrote:
I have been programming for a few years but have not been in a position to do it full time, I am really a lead install tech that can also program. I would like some input from the group on how to widen my programming abilities. It would seem like most of the things learned would come necessity. what i mean by that is that I learn how to program code for a specific piece of gear because I need to for a job. But what are some thing I could do to basically prep myself for upcoming needs? Any input would be appreciated.
|
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.
toggle quoted message
Show quoted text
--- 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
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'm not sure I'd call it an "issue" in terms of the original phrasing. The MC3/PMC3/PMC3-XP has one IR generator that is multiplexed amongst the 5 ports. If you turn port 2 while Port 1 is generating, Port 1 will finish the min # of repeats for the given IR command Port 1 is generating, then it will start generating Port 2.
toggle quoted message
Show quoted text
--- In Crestron@..., Steve Kaudle <crestron@...> wrote: As I understand it, if you try to send two IR commands at the same time (not sure if that means an overlapping time duration of the associated digitals, logic wave, or logic solution), one or more of the IR commands will be generated as a single, minimum pulse.
On 4/12/2012 8:50 PM, Witmarquzot wrote:
From what we saw on this group i believe it would stopped if you tried to use two ports at once i think?
It is not labeled as an easy search (MC3 Problems, MC3 Feedback, MC3 IR). Must have been January/Febuary, might have been November
--- In Crestron@..., "floyd1212"<floyd1212@> wrote:
What's the problem with simultaneous IR on the MC3?
--- In Crestron@..., "Witmarquzot"<tdurrant420@> wrote:
Still vapor ware at this point, so who knows
--- In Crestron@..., "John"<ComeAlive@> wrote:
Does the CP3 have the same issue as the MC3 with regards to simultaneous IR output
------------------------------------
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
|
Haha Anthony, You've pointed out a mistake in the articulation of the point I was trying to make! Rather than trying to insinuate that Crestron (AMX or any other competitor) programmers are different than the average PC programmer, I was actually getting at the fact that we're NO different, yet we continue to act like we are. The PC programming industry has about 20+ years on the AV control system programming industry, and if you look at the timeline's of their progression it's laughable that we're still about 20 years behind in many aspects on the AV side. My point is exactly that we are every bit as egotistical and arrogant as PC programmers, but as an industry, they've been forced to work together and collaborate far more than we do, and as a result have matured as an industry (* note I did not say mature as individuals ;) ). Because most AV programmers (even in CAIP firms or large commercial companies like where I am) tend to work alone, as "lone wolves", and while we may occasionally try to sit in the same room together and tolerate each others ideas and presence, we haven't been forced to truly collaborate. Then we might actually learn a thing or two! </second rant> On Fri, Apr 13, 2012 at 2:02 PM, Anthony Desimone < anthony_desimone@...> wrote: **
By and large, I agree but I think you have a little green grass syndrome going on. The average crestron programmer is surprisingly similar to the average programmer. There arrogance and desire to rewrite the wheel is extremely prevalent.
There are certain areas where there is a lot of great open-source collaboration, but there are also sectors where everything is locked down pretty tight and you really see this culture largely perpetuated by the OS downwards.
I couldn't agree more though about a team all being on the same page. Anything else really spells disaster.
--- 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...>
|
PMC2 not recognized on Tool Box
Well, just got a PMC2 from a customer that was in the office and I decided to take it home and see what happens to, I hook up via USB Hit Device discovery Tool, nothing came on, Unplug USB connected to router, hit Discovery Tool, nothing came on, When to the App Fing to check Ip's on the network and only my phone, router and PC were available, no PMC2, anyway I can Reboot this and bring it to life?
Thanks on advice!!
|
By and large, I agree but I think you have a little green grass syndrome going on. The average crestron programmer is surprisingly similar to the average programmer. There arrogance and desire to rewrite the wheel is extremely prevalent.
There are certain areas where there is a lot of great open-source collaboration, but there are also sectors where everything is locked down pretty tight and you really see this culture largely perpetuated by the OS downwards.
I couldn't agree more though about a team all being on the same page. Anything else really spells disaster.
toggle quoted message
Show quoted text
--- 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...>
|
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...>
toggle quoted message
Show quoted text
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
|
Re: Best way to widen my programming ablility
For programming generally... in my experience just play with things: I have Crestron in my home not because it's cool (ok, not _only_ because its cool) but because I can try things without worrying about pissing people off* or wasting billable time or...
Don't be afraid to attempt to reinvent the wheel. Sometimes it will work poorly, sometimes it will work well, sometimes it won't work at all. Worst case it helps you to understand why "the way we've always done it" is the way you should continue to do it.
For onsite... don't limit yourself to active sawmills. For the best variety also consider hiring someone to
a) Test the fire alarm for hours at a time (alternate between just a temporal 3 horn and voice evacuation for maximum effect)
b) Hit the main circuit breaker for the building you're in, run into the room and tell you that they're "just testing the generator...the power won't be off for more than a half hour or so". Have him turn the circuit breaker on without any warning after about an hour. Then turn it off again after 5 minutes with no explanation.
c) Find someone doing renovations and have them sand drywall no more than 6 feet away from where you're working.
d) Send random college students, homeless, or wayward tourists in to ask you inane questions that have nothing to do with the project at random intervals (bonus points if you can find someone with the impeccable timing to pop in just as you finally think you've figured out something weird)
e) (More for multi-room systems than single-room systems) Try to work in such a way that anyone using the system can continue using the system without even noticing you're working on a different part of the system.
Lincoln [* -- My girlfriend used to think my house is a sentient being and jealous of her. I think I've convinced her otherwise but...] -- Lincoln King-Cliby, CTS Sr. Systems Architect | Crestron Certified Programmer (Silver) ControlWorks Consulting, LLC V: 440.449.1100 x1107 | F: 440.449.1106 | I: Crestron Authorized Independent Programmer
toggle quoted message
Show quoted text
-----Original Message----- From: Crestron@... [mailto:Crestron@...] On Behalf Of matt_rasmussen_2000 Sent: Friday, April 13, 2012 2:36 PM To: Crestron@... Subject: [Crestron] Re: Best way to widen my programming ablility There's no substitute for practice... to make it more realistic, be sure you sit on a 5-gallon bucket in an active sawmill and give yourself a deadline of 15 minutes until the CEO's presentation starts.
Too true, too true... ------------------------------------ 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
|
Re: OT: Polycom HDX8000 w/BSS AEC but using analog dialer in the HDX8000 question
It's a real analog line or a module who convert an ip extension into an analog extension. i have seen this in the past and it was cause by the device who create the analog line.
toggle quoted message
Show quoted text
--- In Crestron@..., "matt_rasmussen_2000" <mjrtoo@...> wrote: For some reason I've been assigned the task of figuring out this issue and wondering if someone here can help out real quick.
An older Vortex system was replaced with BSS and a new HDX8000, but the engineer didn't understand that the old EF2241 had an analog phone dialer and didn't include one in the BSS (used the BLU-101 instead of the 102). So, they are using the analog phone input of the HDX8000 to dial those calls. As far as programming goes, it's working fine, but it appears that the analog phone calls are half-duplex, so if someone is talking in the local room, or, an audio source is playing, the far site on the phone call cannot be heard or interrupt the local conversation. The video conference audio is just fine, full duplex communication etc. The BSS is currently setup to do the AEC processing in the system and the AEC is off in the codec.
I guess I don't understand why the analog phone would be any different than the video conference audio coming out of the codec and processed by the BSS? I've looked through the menus of the codec to look for any settings for the analog dialer, but I can't see anything that would set it up for half duplex. Or, maybe the dialer in the HDX8000 is just half-duplex?
|
OT: Polycom HDX8000 w/BSS AEC but using analog dialer in the HDX8000 question
For some reason I've been assigned the task of figuring out this issue and wondering if someone here can help out real quick.
An older Vortex system was replaced with BSS and a new HDX8000, but the engineer didn't understand that the old EF2241 had an analog phone dialer and didn't include one in the BSS (used the BLU-101 instead of the 102). So, they are using the analog phone input of the HDX8000 to dial those calls. As far as programming goes, it's working fine, but it appears that the analog phone calls are half-duplex, so if someone is talking in the local room, or, an audio source is playing, the far site on the phone call cannot be heard or interrupt the local conversation. The video conference audio is just fine, full duplex communication etc. The BSS is currently setup to do the AEC processing in the system and the AEC is off in the codec.
I guess I don't understand why the analog phone would be any different than the video conference audio coming out of the codec and processed by the BSS? I've looked through the menus of the codec to look for any settings for the analog dialer, but I can't see anything that would set it up for half duplex. Or, maybe the dialer in the HDX8000 is just half-duplex?
|
No, I'm not thinking a code generator or any type of automated tool. I'm thinking more a framework of standards programmers could develop and agree to follow so that different programmers could develop functional blocks that interoperate. I suspect just getting agreement on some big issues would be difficult (like TP-room-device vs. TP-device), but it might be worth doing.
If you were just kidding with that question, ha ha, good one ;-).
Barry
toggle quoted message
Show quoted text
On Apr 13, 2012, at 2:20 PM, matt_rasmussen_2000 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
------------------------------------
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
|
|
Re: Best way to widen my programming ablility
Best "learn to program" website I've ever seen is www.codeyear.com The best part is there is NO videos!!
Mark
toggle quoted message
Show quoted text
On Fri, Apr 13, 2012 at 1:48 PM, coreygsimpson <coreygsimpson@...>wrote: **
I have been programming for a few years but have not been in a position to do it full time, I am really a lead install tech that can also program. I would like some input from the group on how to widen my programming abilities. It would seem like most of the things learned would come necessity. what i mean by that is that I learn how to program code for a specific piece of gear because I need to for a job. But what are some thing I could do to basically prep myself for upcoming needs? Any input would be appreciated.
|
Re: Best way to widen my programming ablility
"Handy reference here: Teach Yourself Programming in Ten Years: Now that was a good read lol. I'm a long time student of the school of hard knocks, and a proud University dropout.... -Neil On Fri, Apr 13, 2012 at 12:25 PM, Jeremy Weatherford <xidus.net@...>wrote: **
Handy reference here: Teach Yourself Programming in Ten Years:
Specific to Crestron, make sure you get to training classes, as they will teach you things that are difficult to learn on your own. Get your own processor (QM-RMC or DIN-AP2) if you don't already have one to test things on. Get familiar with Debugger, explore existing programs in it and make sure you really understand how they work, and not just what they do. Read the SIMPL Primer and the symbol help files. Make sure you know what all the symbols in the symbol library do -- that will come in handy some day when you're saying "I know there's a symbol that does X..." even if you don't remember exactly what it's called. Many of the more complex symbol help topics also give examples of how you might use them. If you're not sure how something works, write a little test program so you can poke the symbol in Debugger and see what happens.
Learn to read protocol documents... I enjoy when people post questions about protocols on this group, because, time permitting, I try to decipher the protocol myself, whether or not I can answer their actual question. The more protocol documents I decipher, the easier it is to interpret new protocols.
Identify your weak spots and start practicing with them. Crosspoints? SIMPL+? Serial parsing in SIMPL? Analog logic? Modules? Hex/ASCII/decimal data formats? Page flip logic? What are some things that you might be asked to add to a program that would be useful to practice beforehand? Timeserver synchronization? XPanels? iPads? Lamp hours? Countdown timer for a presenter? Weather/news/stock tickers?
There's no substitute for practice... to make it more realistic, be sure you sit on a 5-gallon bucket in an active sawmill and give yourself a deadline of 15 minutes until the CEO's presentation starts.
On Fri, Apr 13, 2012 at 1:48 PM, coreygsimpson <coreygsimpson@...> wrote:
I have been programming for a few years but have not been in a position to do it full time, I am really a lead install tech that can also program. I would like some input from the group on how to widen my programming abilities. It would seem like most of the things learned would come necessity. what i mean by that is that I learn how to program code for a specific piece of gear because I need to for a job. But what are some thing I could do to basically prep myself for upcoming needs? Any input would be appreciated.
------------------------------------
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
[Non-text portions of this message have been removed]
|