Monday, August 20, 2007
Controller programming library 2
How do we differentiate controller A to B? I/O, point assignment and sequence.
If we have a master I/O list for all controllers, it's easy to figure out the difference between them by putting them side by side.
I would like to have the software cover the difference of point assignment for the programmers as long as they are in one controller. As I mentioned before, the logic layer is above the physical point assignment and it won't be affected by the order of I/O or pseudo points in a controller.
Now, here comes sequence. In TXT library, I setup modules that match the sequence blocks on the drawing. And I setup CID that represent the selected sequences in each controller. While that works pretty well, it may not fit all real applications.
Firstly, one controller may have more than 1 units. So CID must be arranged per unit.
Secondly, there are always new sequences that were not included in the library. So the library has to be updated.
If we have a master I/O list for all controllers, it's easy to figure out the difference between them by putting them side by side.
I would like to have the software cover the difference of point assignment for the programmers as long as they are in one controller. As I mentioned before, the logic layer is above the physical point assignment and it won't be affected by the order of I/O or pseudo points in a controller.
Now, here comes sequence. In TXT library, I setup modules that match the sequence blocks on the drawing. And I setup CID that represent the selected sequences in each controller. While that works pretty well, it may not fit all real applications.
Firstly, one controller may have more than 1 units. So CID must be arranged per unit.
Secondly, there are always new sequences that were not included in the library. So the library has to be updated.
AX domain-wide authentication
a. Add a String slot to the WebService and name it cookieDomain.
b. Enter the domain name in the field.
c. When domain name is used the cookie will log you on with the same
logon of the first station. If you do not have the stations registered in your
DNS Server you can workaround by putting the host in the host file
(Platform/TCP/IP Configuration).
i. For example:
cookieDomain = tridium.com
host file:
jace1.tridium.com
jace2.tridium.com
jace3.tridium.com
192.168.1.100:82/ord?station:|slot:/Drivers/LonNetwork/VAV_001
b. Enter the domain name in the field.
c. When domain name is used the cookie will log you on with the same
logon of the first station. If you do not have the stations registered in your
DNS Server you can workaround by putting the host in the host file
(Platform/TCP/IP Configuration).
i. For example:
cookieDomain = tridium.com
host file:
jace1.tridium.com
jace2.tridium.com
jace3.tridium.com
192.168.1.100:82/ord?station:|slot:/Drivers/LonNetwork/VAV_001
Controller programming library
How to easily figure out the difference between 2 controller programming? Or more?
By point table? CVAHU02a to CVAHU01b, +FrzAlm +OaFlowSig +RaCO2 +RmRh
Following common sense, I know FrzAlm will stop fan in emergency. I don't know if those 3 additional AI are for monitoring only or acutually bring in more sequence.
By CID? +33(CO2 control) +34(outside air flow measurement and control)
Combining point table, I get a rough idea of what's the differece. But there's more.
Inputs, outputs, AV and BV assignments. I can ignore this in TXT library, since the logic layer is abstract and points are identified by their name, not the physical assignment. But in GRA library, I lose the control and the tool does not separate them. When I move programs from CVAHU01b to CVAHU02a, points are associated with their ID, not name. Very ugly! I have to manually go through each point to make sure logics are not connected to wrong points due to assignment changes.
The differences are always I/O, assignement and sequence. But the above process only applies to those controllers in the library. In real projects, things are more complicated. Normally, they don't have CID. (CID reminds me of how I differtiate controllers when I programmed them and they came from sequences.)
I have to identify them on HW drawings, in sequences. And they were checked by HW designer but this very simple result was left outside of the drawings. It's too bad that one can not pass all the useful information to downstreams.
That's why we need a revolution of the design process. Some of the key elements helping efficient engineering have to be identified and recorded at the very beginning of the job.
Great success begins at the beginning!
By point table? CVAHU02a to CVAHU01b, +FrzAlm +OaFlowSig +RaCO2 +RmRh
Following common sense, I know FrzAlm will stop fan in emergency. I don't know if those 3 additional AI are for monitoring only or acutually bring in more sequence.
By CID? +33(CO2 control) +34(outside air flow measurement and control)
Combining point table, I get a rough idea of what's the differece. But there's more.
Inputs, outputs, AV and BV assignments. I can ignore this in TXT library, since the logic layer is abstract and points are identified by their name, not the physical assignment. But in GRA library, I lose the control and the tool does not separate them. When I move programs from CVAHU01b to CVAHU02a, points are associated with their ID, not name. Very ugly! I have to manually go through each point to make sure logics are not connected to wrong points due to assignment changes.
The differences are always I/O, assignement and sequence. But the above process only applies to those controllers in the library. In real projects, things are more complicated. Normally, they don't have CID. (CID reminds me of how I differtiate controllers when I programmed them and they came from sequences.)
I have to identify them on HW drawings, in sequences. And they were checked by HW designer but this very simple result was left outside of the drawings. It's too bad that one can not pass all the useful information to downstreams.
That's why we need a revolution of the design process. Some of the key elements helping efficient engineering have to be identified and recorded at the very beginning of the job.
Great success begins at the beginning!
Saturday, August 11, 2007
Computer tools
Saturday, August 04, 2007
My Tridium R2 tools 1
I thought about this over a year, and finally upgraded my tools of importing NVs from Excel 50/500 controllers and converting them to program objects.
There are 2 ways, from CARE printout or from LonSchemaManager of Dynamic device. They are separate exe files now. Maybe in next upgrade, I'll combine them together.
The improvements are:
1) Before LonSchemaManager, I was using web property page of each Dynamic device, which requires additional webUI, live station and Excel as a temporary media. LonSchemaManager is much easier to get, even from a offline station.
There was an even earlier version, which requires a man-made Excel spreadsheet. The Excel spreadsheet was a part of the turnover documents from the CARE guy. But I didn't like it. Firstly, it costs more CARE guy's time and sometimes he just simply cannot provide it. Secondly, it may not reflect the true settings in CARE, since it's a manual process, and any human mistake may happen.
2) The software now shows an editable table of all NVs instead of directly generating codes in text windows and leaving no interface for human reviewing and editing. Single or multiple continuous NVs can be manually deleted. It's sorted by NV names. For further orgnizing, these NVs can be copied to and pasted from Excel.
3) The CARE version now supports automatically removing bound NVs from the NV list, which saves a lot of my manual filtering time.
4) Generally, the LonSchemaManager version should support all 3rd party Lon controllers. But I don't have enough time to review the program object code. In next upgrade, if possible, I would like to have a configurable code template to make this tool more generic and flexible.
There are 2 ways, from CARE printout or from LonSchemaManager of Dynamic device. They are separate exe files now. Maybe in next upgrade, I'll combine them together.
The improvements are:
1) Before LonSchemaManager, I was using web property page of each Dynamic device, which requires additional webUI, live station and Excel as a temporary media. LonSchemaManager is much easier to get, even from a offline station.
There was an even earlier version, which requires a man-made Excel spreadsheet. The Excel spreadsheet was a part of the turnover documents from the CARE guy. But I didn't like it. Firstly, it costs more CARE guy's time and sometimes he just simply cannot provide it. Secondly, it may not reflect the true settings in CARE, since it's a manual process, and any human mistake may happen.
2) The software now shows an editable table of all NVs instead of directly generating codes in text windows and leaving no interface for human reviewing and editing. Single or multiple continuous NVs can be manually deleted. It's sorted by NV names. For further orgnizing, these NVs can be copied to and pasted from Excel.
3) The CARE version now supports automatically removing bound NVs from the NV list, which saves a lot of my manual filtering time.
4) Generally, the LonSchemaManager version should support all 3rd party Lon controllers. But I don't have enough time to review the program object code. In next upgrade, if possible, I would like to have a configurable code template to make this tool more generic and flexible.
