Reply to Thread

Looking at the cost of living in MA I suspect the garbage men would have to make 6 figures. Here in Omaha that's a nice income! I don't know, I still haven't made up my mind whether to accept this challenge or go union and avoid the stress, make the same money with incredible benefits. I would have almost no health ins. costs, full pension paid for, free tools, guaranteed annual raises...or none of the above. But in the union I may be faced with weeks of boring grunt work. Cleaning boilers, punching chiller tubes, washing out cooling towers, who knows? Actually, that doesn't sound too bad compared to being holed up in a mech room sitting on a 5 gallon bucket with my laptop, wondering why my program doesn't work or the points won't pass!

Originally Posted by man from trane

Thanks for all the insights, jlaber! I think it will be years before we get to the point where I'm doing programming all day. A steep learning curve doesn't excite me at all. We're a residential HVAC contractor with a commercial department. I'm a commercial tech, but spend most of my time working on splits and RTUs, which is getting old fast. It's even harder to work on that all day and then switch over to learning a new career, essentially. The Spyder on the AX platform has almost no resemblance to anything I've worked with in the past.

I could quit today and go work for a union mechanical contractor as a service tech with awesome benefits, doing boilers, chillers, etc. It seems like an easy choice, but I don't want to let my current employer down.

Yes, it doesn't seem to matter what level of involvement one has with controls programming. Based on the comments from most others in the industry - PMs, sales, operations managers, business owners, commissioning agents, balancers, site superintendents, even carpenters, bricklayers and laborers - it's become very very clear to me that the programmer is the one stuck with the greatest levels of frustration. It would be great if either the products were designed so that the work flow is extremely efficient, or all the above people the programmer depends on have their jobs done well in advance of the scheduled completion date. After more than 10 years in the field things are still getting worse. There are more devices added, like CO2 sensors and airflow stations, and the sequences are becoming more complicated, not to mention less sensible, the products more complicated and slower to program, schedules getting tighter, customer expectations greater, plus exponential increases in tech support calls, you name it, if it make the field programmer's job harder and more frustrating, it will happen. Did I mention all the different incomatible versions of software, the dependence upon third party software that keeps changing and breaking existing installations, such as Java updates? Or integration into packaged units like boilers, chillers and AHUs with factory-supplied controls that communicate via standardized protocols. It sounds like a great idea, but the reality is that packaged controls run a fixed sequence, yet the DDC programmer is tasked with making them fit a custom sequence, so we're stuck with making it work half-way by programmatically manipulating setpoints and overrides. By far, it is a lot more sensible to specify a blan-slate mechanical system and control it 100% via DDC. However, the very purpose of Lon and BACnet is for every manufacturer to be able to get their little piece of controls into the sales quote.

I don't want to let my employer down either. He's great to work for. It's the situations we get into and the nature of the contracting business we are faced with in the field that brings me closer to just turning my back on it all so I can go back to a modest-paying office job where I can take vacation time like everyone else does, in the summer because that's when my wife is off (teacher), and be treated with maybe a tiny little bit of respect. So if anyone would like to make 6 figures doing what I do, sooner or later there I will be leaving an opening.

Thanks for all the insights, jlaber! I think it will be years before we get to the point where I'm doing programming all day. A steep learning curve doesn't excite me at all. We're a residential HVAC contractor with a commercial department. I'm a commercial tech, but spend most of my time working on splits and RTUs, which is getting old fast. It's even harder to work on that all day and then switch over to learning a new career, essentially. The Spyder on the AX platform has almost no resemblance to anything I've worked with in the past.

I could quit today and go work for a union mechanical contractor as a service tech with awesome benefits, doing boilers, chillers, etc. It seems like an easy choice, but I don't want to let my current employer down.

Originally Posted by klrogers

If your heart is not in it you are probably better not doing controls Spyder's is not the easiest controls to work with that for sure, but these days, depending on the type of buildings and system you are installing there is usually multiple devices to "integrate" that will require more than a single piece of software.

Kevin

Originally Posted by klrogers

If your heart is not in it you are probably better not doing controls Spyder's is not the easiest controls to work with that for sure, but these days, depending on the type of buildings and system you are installing there is usually multiple devices to "integrate" that will require more than a single piece of software.

Kevin

Well, like the controls world, this forum software has holes in it, so the long-winded post I just typed disappeared because the system decided to log me out and upon returning to the reply page it was all gone.

Short story is, it's not just Spyder. It's a lot of controls systems, if not all of them. Similar to the way that experieced DOS-based programmers/users suffer from over-complicated and bloated GUIs that are perceived as superior by those who don't want to take the time to learn how to use faster, more efficient software of the old days, control systems are following suit. Concepts such as object-oriented languages and graphical programming could very well be designed as well as the older software so that it works just as fast and reliably, but the trend I am seeing (based on prior product development experience) is that manufacturers no longer build upon the wisdom that, once upon a time, was valued and passed down to the younger generations. The result is inexperienced product developers, and with no oversight from well-seasoned old-timers, the doors are wide open for ignorance and arrogance to prevail. My analogy is: why don't chemists develop something better than water? Maybe because enough people understand the merits of water, not to mention absolute dependence upon it. However, far fewer people understand the merits of simpler, faster, more efficient software, so every newbie who enters the software engineering market today has the notion that they will be the next Einstein, and with inexperience comes the notion that "I have a better idea, and it can't be compromised by some old fart slowing down my progress, so let's throw out all the old concepts and re-invent the wheel from the ground-up".

Another factor is the nature of contracting and DDC sales. We are usually not selling to the people who use the systems, and certainly not the programmers. We are selling to executives who write the checks, so top priority in product development is to create new features that look good on a salesman's quote. As a programmer, your job is to just make it work regardless of whether the process keeps getting harder, more over-complicated, and slower, while the customer is under the impression that the opposite is true.

No need to remind me to get out of the DDC field-programming business, that's already in the works. Once upon a time I developed computer-based musical instruments and recording equipment. From that world comes some very strict marketing rules. Any musician or recording engineer would laugh hysterically if they hit a note on a keyboard or turned a knob and had to wait 100 milliseconds, let alone seconds or minutes, to hear a response. Don't bother telling me that DDC is far more complicated until you've designed a keyboard to be able to respond to 10 notes simultaneously with limited hardware resources, without any perceptible delay, plus creates sounds that musicians want. Also don't bother thinking that the slightest hole or inconvenience in the user interface wouldn't cause the community to criticize the product hysterically, instantly dropping sales to zero. Most software engineers who intern for companies that build brilliantly-designed, fast-reacting musical instruments simply move on to other jobs where none of this matters. It's an incredible amount of hard work, and involves a lot of old-fashioned techniques like assembler-based code, FPGAs, RISC processing and real-world testing, testing testing and re-testing. They didn't go to college for their jobs to be hard. But on the other hand, the employers value their programmers a lot more than a general contractor will appreciate the frustrations that a DDC programmer will experience, so the working conditions are far, far, far more favorable.

I've learned that to survive this industry, you need to take your heart OUT of it, and just become numb to all of the BS that you will be swimming in all day every day. It's far more about chugging along, making it work, and not caring whether you have any opportunity to become good at what you do, or whether you find any sense of gratification in it. There will never be gratification to be had for a DDC programmer. The harder you work at providing a quality product, the more time it takes, and the more you will be spit in the face and thrown under the bus. And don't bother complaining, lest you will be deemed a lazy, candy-a** p***y who has never swung a hammer or sweat in his life. And yes, I've swung hammers, and rebuilt engines, and replaced 50-year old AHU shafts on 50 HP blowers, so take my opinion for what you feel it's worth. Sure I cussed, got injured and dirty, but at the end of the day at least you could say the job was done, done done. It was easy to see it was done, and there was rarely a request to go back and re-do the work because the customer's whim dictates that they didn't like the way it was designed to work.

So, despite my extreme frustrations due to the above mentioned circumstances of our industry, there are good things to mention about Spyder. The graphical programming model is decent, and when there's a problem, the debug mode will lead you right to it. The Niagara-based environment will back up you entire project with a single command. The Spyder will indicate when something is left in manual override, and has facility to cancel overrides via a single command. To avoid the pitfalls that led me to post earlier in great frustration, I recommend that you license a PC or Windows-based niagara box to temporarily install on site if you want to do remote Spyder programming. An embedded JACE (like a JACE-6 for example) will work, but at some point, resources are likely to run short, and you may end up chasing your tail because all kinds of weird stuff could happen, or if you're lucky, it will just crash and reboot itself and you'll lose your work. If you can reduce frustrations on that front, at least you'll have more room to deal with real-world problems like your controller power being switched on and off all day, space sensors disappearing, balancers scheduled to start while you're still in the middle of programming, and the plethora of baloney that the construction industry has to offer. GCs don't care whether you need to have steady power, and that your field devices need to stay installed, and that all devices must be on line before attempting to commission/bind a Lonworks network (at least in Niagara). All I've ever heard is "not my problem". You need to get it working, doesn't matter whether it's physically possible. You can't explain something to someone who refuses to understand. So, as long as there is no heart, no pain will be felt. Just go do the work, and most definitely don't take the situations you're faced with to heart. Or if you're smart, build your business strictly on design-build projects for retrofit jobs that you've sold directly to the building owner. In that case you'll be in much better control of the circumstances, and won't have GCs, construction schedules and liquidated damages looming while you run into unexpected technical setbacks.

You can create a batch file to start Workbench and the platform daemon for the version you are opening. You will still need to make a platform connection to start a station on your laptop and then the station connection. Not a big deal, takes about 15-30 sec depending on the size of your station. If you are connecting to a jace then you can just log right into the station once Workbench is opened.

Do you need a batch file for XP or Windows 7?

If you are not familiar with AX or Spyders then you are in for a big learning curve.

If your heart is not in it you are probably better not doing controls Spyder's is not the easiest controls to work with that for sure, but these days, depending on the type of buildings and system you are installing there is usually multiple devices to "integrate" that will require more than a single piece of software.

Kevin

Originally Posted by jlaber

Pfft. Don't feel stupid or bad. Been using Lon Spyders for years, and every time I download a control program the bindings quit working. Re-commissioning the Spyder I'm working on and all the Spyder it has Lon links to, then doing a Selective Bind rarely fixes it. I need to commission/bind the entire network, which on the current job takes about 1.5 hours. Since the programming changes I'm making require the schedule input nvi to work for testing, it basically takes 1.5 - 2 hours just to make one little programming change and test it. I've been working on one Spyder for 15 hours now, and still haven't worked out a few simple programming changes. Latest 3.7 Spyder tool. Still the same @#$%^&*_*&*^%^$#ing problems.

My company wants me to get our new controls division up and running (it currently doesn't exist) using these new Spyder controls with the AX front end. The last controls I worked with was Tracer Summit back around 2007. I'm lost right now with Spyder even after 9 hours of training. Is it just this system, or are all of the current generations of controls (KMC, Alerton, Johnson, Siemens, etc.) this confusing and difficult? Just to get into programming the stupid thing I have to start this platform, log in, start this and that service, log in, connect this, start that, it's ridiculous! Why can't there be a batch file that starts up everything on my laptop and brings me to a simple login screen just like every other system I've ever worked on?

I guess what I'm looking for is the info I need to figure out if this is something I'm going to be able (and willing) to learn in a short time. If not, we either need to pursue a different system or I need to pursue a different company. I was a full-time controls tech for several years and got burned out on it. Now I primarily do Commercial HVAC/R service work and have been enjoying that. I told this company I didn't want to do full-time control work but I guess they didn't hear me. Supermarket Racks are what I really love, but we don't do that.

Pfft. Don't feel stupid or bad. Been using Lon Spyders for years, and every time I download a control program the bindings quit working. Re-commissioning the Spyder I'm working on and all the Spyder it has Lon links to, then doing a Selective Bind rarely fixes it. I need to commission/bind the entire network, which on the current job takes about 1.5 hours. Since the programming changes I'm making require the schedule input nvi to work for testing, it basically takes 1.5 - 2 hours just to make one little programming change and test it. I've been working on one Spyder for 15 hours now, and still haven't worked out a few simple programming changes. Latest 3.7 Spyder tool. Still the same @#$%^&*_*&*^%^$#ing problems.

One of the 'glitches' I noticed about the Spyders when getting them to play nice with an AX integration is that when you edit anything in the control program page, it will signal that it requires a download (little red arrow tilted downward over the device in the Nav tree). Though this doesn't always hose up the controller, it may unbind links (especially if you add NVIs, NVOs). I find that downloading requires the initial Commission command with the proper Neuron ID. Then perform the Action/Download Controller command. Then a SECOND Commission command, ensuring the proper neuron ID (don't ask me why but it works). After applying, you must then bind the Links. I would do this after each controller as unbound links will quickly hose up the Lon network. This 'ritual' must be adhered to or you will experience a world of hurt. Glitchy. Quirky. Yeah, but they do work after you let them go.

Hope that helps

I'm using PVL4022 Spyders on the VAVs and PUL6438 for the RTUs, if you guys could send whatever you have that will at least give me a start to tuning the programming to my liking. Thanks for the note on the economizer and staging issues.

Email is in my profile.

Chad

The problem with the economizer is that it will stay enabled on a call for heat.

I think that is the same one we have L Warren. I don't have access to it till tonight will send it then if your email is in your profile. Otherwise email me - my email is listed in mine.

I haven't done anything with the economizer yet and I don't like the way it stages heat and cooling - going to rewrite that piece.

If Rick has the same one I do, there is something that you will need to modify in the program to make it work properly if you have economizers ont the RTU that you are controlling with the Spyder program.

Also if you are using XL10's for your VAV's instead of Spyders you will have to modify the program for that as well.

Originally Posted by Rick_h

It'll just make your learning curve happen faster Digo - out of necessity.

Luckily there are places like this to help.

My next phase is 5 Spyders that will be working together doing demand ventilation in an automotive plant. That will be crunch time - I can't afford downtime there - it has to go smooth.

BTW Honeywell came through and sent me a sample program they are testing. But thanks to everyone for there time - I appreciate the input.

Rick

Rick, I'm working on a project right now with RTUs with heat in the RTU and about 10 zones per unit. We are making the zone VAVs pressure independant, and i'm sitting here scratching my head about how to program these RTUs heat/cool mode changeover by measuring zone heat and cool calls. What is this sample program that you mention. How did it workout for you? Would you mind sharing the program?

Thanks,

Chad

Originally Posted by digo

The swimming is in reference to the spyder's beta name: piranha.
Either way, they can bite.

how true that is is

Originally Posted by Rick_h

OOPS Digo - you weren't kidding about swimming in them LOL - I hadn't noticed the picture earlier.

The swimming is in reference to the spyder's beta name: piranha.
Either way, they can bite.

OOPS Digo - you weren't kidding about swimming in them LOL - I hadn't noticed the picture earlier.

It'll just make your learning curve happen faster Digo - out of necessity.

Luckily there are places like this to help.

My next phase is 5 Spyders that will be working together doing demand ventilation in an automotive plant. That will be crunch time - I can't afford downtime there - it has to go smooth.

BTW Honeywell came through and sent me a sample program they are testing. But thanks to everyone for there time - I appreciate the input.

Rick

I wish I had a 3 zone system to deal with right now, but instead I'm swimming with spyders...