I can't seem to find a tag to represent Variable Frequency Drives. Am I simply missing it? If not, it seems like this is something that needs to be added.
Thanks,
George
Brian FrankThu 1 May 2014
We don't have an explicit vfd tag. But at the point level its sort of implied. For example if a fan point is numeric with a "%" unit rather than boolean its implied to be a VFD fan.
But should we create explicit vfd tag? Applied to points or equip? Only when we break out fans/pumps as their own equip entity? Need comments
Jason BriggsThu 1 May 2014
We still need to model fans, vfds, and their relationships.
We for sure want to create a vfd tag, and we need to figure out if a vfd should be an equip.
Leroy SimmsWed 7 May 2014
I agree a vfd or vsd tag could be useful; a "%" cmd could indicate some other type of capacity control such as fan inlet guide vanes.
Jason BriggsFri 9 May 2014
My vote is that if you have more then a couple points, then you stick it in it's own equipment. I know this kind of sucks, but the trade off I think will be best.
Basically for VAVs, Fan Coils, Rooftops, etc... You will always model the fan as apart of the equip, but an ahu if it has more then a couple points, go ahead and move that to a sub equip.
This might make the rule a little harder but it's better than having to model a VAV with a SS for a fan as a sun equip.
Brian FrankMon 12 May 2014
Okay there has been a lot of very good discussion on this topic which I would like to bring it to a close and get a final decision.
It has been a long running open issue about whether to model VFDs as a sub-equip or to flatten them into the parent equipment. This is what I'm going to propose:
Pumps and the pump tag are always pulled out into a separate piece of equip
Fans are optionally pulled out into a sub-equipment, or if there is just one or two points the may be flattened into the parent equipment
I think we all agree that pulling fan points out into a separate sub-equip gives us consistently. However, its at the expense of simplicity - there are lots of equipment where modeling a Fan as sub-equip is complete overkill such as VAVs, fan coils, simple RTUs, etc. I think we need to leave this to the discretion of the project and how sophisticated the equipment model needs to be.
Nick has posted an excellent set of point tagging for VFD points. I think we should discuss and finalize that (which will also require making a final call on the status/enable/run point conventions). But before diving into that discussion, I would like to focus on the question above.
So, can we get agreement on this proposal so far? Pumps are always equip and Fans are optionally flattened or pulled out into VFD sub-equip
Keith BishopWed 14 May 2014
While I think that you should be able to model a pump as a sub-equip, I can’t think of a good HVAC example or situation where it would be used. With that said, I agree with the adoption of this standard.
Another concept that should probably be part of this thread: Should a compressor be handled similarly to a fan? If it exists as part of a simple system and there are few points associated with it, the compressor could be flattened out as part of the larger equip (normal case). In a few situations, we have had compressors with a larger amounts of data associated with them and have modeled them as individual sub-equips. The use of this model may not make sense with the majority of compressors but there is a move with several equipment manufacturers to use variable compressors on their larger units which I think justifies it. I know this concept is a little late to this topic stream, but I thought I’d bring it up.
Brian FrankTue 27 May 2014
Another concept that should probably be part of this thread: Should a compressor be handled similarly to a fan?
I think we could treat compressors like we do fans - as simple points flattened into their parent equip or as a sub-equip based on the situation.
Okay, my original proposal from 12 May has been out there for several weeks. So unless someone else chimes in, then lets considered that decided. Fans can be a single point or a sub-equip based on situation.
Next step: additional tags for VFD equip and VFD points. Before tackling points lets tackle equip level tags using Nick's example from 168:
In this example we use the standard tags associated with a fan position in the AHU: discharge, return, outside, exhaust. For VAV we'd use discharge. That seems safe to standarize, but comments welcome.
I think there was general consensus that we should have a vfd tag. So I'd say that should be included on a VFD fan.
Nick's example also use horsepower which seems genuinely useful to standardize. However the term itself is not really a modern SI unit. Do we want this? And if so, what term and unit(s)?
Keith BishopWed 28 May 2014
I think the standard position tags that have been proposed should work.
There definitely needs to be vfd tag but I think we need to do some work on its definition. If we go back to Jason’s 1 May post above, there was a potential to model a VFD as an additional equip. I’m trying to think of an example of when there would be a desire to store information about a VFD outside of the confines of the equip that it drives (fan, pump, etc.). If the information was pulled out of the fan equip and stored in the associated VFD equip, what information would be stored in the fan equip? Also, with information that can be obtained from communicating drives, we could run into a equip, fan, vfd, elecMeter situation. I don’t have an answer for this but I think we should consider these things.
The following could potentially be moved to a new thread on horsepower
There is an existing ‘horsepower' tag with the current implementation being: horsepower, hp; kg1*m2*sec-3; 745.7
Given the factor, this is a definition for mechanical horsepower. I don’t know that it matters, but if we are talking about the name plate information on a motor, it is listed in electrical horsepower.
Since we need to take into account how things are done in other parts of the world, there is a metric horsepower that is used alternatively to mechanical horsepower. It can be defined as:
metric horsepower, (PS or cv or hk or pk or ks or ch); kg1*m2*sec-3; 735.49875 (There are multiple abbreviations)
Given the small difference in factor between mechanical and electrical horsepower and given that any value stated in hp is probably in its final state, I propose that we maintain the horsepower implementation in its current form.
Denis OConnorWed 28 May 2014
While merging my "meta tag" names to be consistent with published Haystack tags for the past few months, I have developed the following tags when I encounter VFDs:
fan speed cmd....... fan speed sensor
pump speed cmd..... pump speed sensor
chiller speed cmd...... chiller speed sensor
The "cmd" is typically an output from the BAS and the "sensor" is feedback from the VFD that may/may not be available.
I am not sure if this creates limitations within SkySpark, but this does give me what I need for analytics and leaves me the flexibility to look at the VFD as a separate piece of equipment if I desire.
Thanks for all of the work everyone has put into this effort. I wish I discovered it years ago.
George Paterson Thu 1 May 2014
I can't seem to find a tag to represent Variable Frequency Drives. Am I simply missing it? If not, it seems like this is something that needs to be added.
Thanks,
George
Brian Frank Thu 1 May 2014
We don't have an explicit
vfd
tag. But at the point level its sort of implied. For example if afan
point is numeric with a "%" unit rather than boolean its implied to be a VFD fan.But should we create explicit
vfd
tag? Applied to points or equip? Only when we break out fans/pumps as their own equip entity? Need commentsJason Briggs Thu 1 May 2014
We still need to model fans, vfds, and their relationships.
We for sure want to create a vfd tag, and we need to figure out if a vfd should be an equip.
Leroy Simms Wed 7 May 2014
I agree a vfd or vsd tag could be useful; a "%" cmd could indicate some other type of capacity control such as fan inlet guide vanes.
Jason Briggs Fri 9 May 2014
My vote is that if you have more then a couple points, then you stick it in it's own equipment. I know this kind of sucks, but the trade off I think will be best.
Basically for VAVs, Fan Coils, Rooftops, etc... You will always model the fan as apart of the equip, but an ahu if it has more then a couple points, go ahead and move that to a sub equip.
This might make the rule a little harder but it's better than having to model a VAV with a SS for a fan as a sun equip.
Brian Frank Mon 12 May 2014
Okay there has been a lot of very good discussion on this topic which I would like to bring it to a close and get a final decision.
It has been a long running open issue about whether to model VFDs as a sub-equip or to flatten them into the parent equipment. This is what I'm going to propose:
pump
tag are always pulled out into a separate piece of equipI think we all agree that pulling fan points out into a separate sub-equip gives us consistently. However, its at the expense of simplicity - there are lots of equipment where modeling a Fan as sub-equip is complete overkill such as VAVs, fan coils, simple RTUs, etc. I think we need to leave this to the discretion of the project and how sophisticated the equipment model needs to be.
Nick has posted an excellent set of point tagging for VFD points. I think we should discuss and finalize that (which will also require making a final call on the status/enable/run point conventions). But before diving into that discussion, I would like to focus on the question above.
So, can we get agreement on this proposal so far? Pumps are always equip and Fans are optionally flattened or pulled out into VFD sub-equip
Keith Bishop Wed 14 May 2014
While I think that you should be able to model a pump as a sub-equip, I can’t think of a good HVAC example or situation where it would be used. With that said, I agree with the adoption of this standard.
Another concept that should probably be part of this thread: Should a compressor be handled similarly to a fan? If it exists as part of a simple system and there are few points associated with it, the compressor could be flattened out as part of the larger equip (normal case). In a few situations, we have had compressors with a larger amounts of data associated with them and have modeled them as individual sub-equips. The use of this model may not make sense with the majority of compressors but there is a move with several equipment manufacturers to use variable compressors on their larger units which I think justifies it. I know this concept is a little late to this topic stream, but I thought I’d bring it up.
Brian Frank Tue 27 May 2014
I think we could treat compressors like we do fans - as simple points flattened into their parent equip or as a sub-equip based on the situation.
Okay, my original proposal from 12 May has been out there for several weeks. So unless someone else chimes in, then lets considered that decided. Fans can be a single point or a sub-equip based on situation.
Next step: additional tags for VFD equip and VFD points. Before tackling points lets tackle equip level tags using Nick's example from 168:
vfd
tag. So I'd say that should be included on a VFD fan.horsepower
which seems genuinely useful to standardize. However the term itself is not really a modern SI unit. Do we want this? And if so, what term and unit(s)?Keith Bishop Wed 28 May 2014
I think the standard position tags that have been proposed should work.
There definitely needs to be
vfd
tag but I think we need to do some work on its definition. If we go back to Jason’s 1 May post above, there was a potential to model a VFD as an additional equip. I’m trying to think of an example of when there would be a desire to store information about a VFD outside of the confines of the equip that it drives (fan, pump, etc.). If the information was pulled out of the fan equip and stored in the associated VFD equip, what information would be stored in the fan equip? Also, with information that can be obtained from communicating drives, we could run into aequip, fan, vfd, elecMeter
situation. I don’t have an answer for this but I think we should consider these things.The following could potentially be moved to a new thread on horsepower
There is an existing ‘horsepower' tag with the current implementation being: horsepower, hp; kg1*m2*sec-3; 745.7
Given the factor, this is a definition for mechanical horsepower. I don’t know that it matters, but if we are talking about the name plate information on a motor, it is listed in electrical horsepower.
Electrical horsepower is defined as Power and Horsepower in Electrical Motors: horsepower, hp; kg1*m2*sec-3; 746.0
Since we need to take into account how things are done in other parts of the world, there is a metric horsepower that is used alternatively to mechanical horsepower. It can be defined as:
metric horsepower, (PS or cv or hk or pk or ks or ch); kg1*m2*sec-3; 735.49875 (There are multiple abbreviations)
Given the small difference in factor between mechanical and electrical horsepower and given that any value stated in
hp
is probably in its final state, I propose that we maintain the horsepower implementation in its current form.Denis OConnor Wed 28 May 2014
While merging my "meta tag" names to be consistent with published Haystack tags for the past few months, I have developed the following tags when I encounter VFDs:
fan speed cmd....... fan speed sensor
pump speed cmd..... pump speed sensor
chiller speed cmd...... chiller speed sensor
The "cmd" is typically an output from the BAS and the "sensor" is feedback from the VFD that may/may not be available.
I am not sure if this creates limitations within SkySpark, but this does give me what I need for analytics and leaves me the flexibility to look at the VFD as a separate piece of equipment if I desire.
Thanks for all of the work everyone has put into this effort. I wish I discovered it years ago.