WebControl - Using WebControl analog inputs in Nodelink

[inovermyhead]

Is it possible to do “arithmetic” in Nodelink on the analog input values from a WebControl 8 board? My situation is a well pump supplied residential water system where I would like to monitor the system pressure. The pressure gauge I'm using outputs a 4-20mA analog signal, which I will convert to a 0-10V analog signal with an intermediate C-to-V converter board, which I then want to pass along to my ISY  via  Nodelink.  I understand that the WebControl 8 analog outputs are integer only and can range from 0 to 1023 in value.   If  possible I would like to convert the 0 to 1023 values to 0 to ~100, for example by dividing them by 10 and calibrating them to psi values. Is it possible to do this in Nodelink?  If so, what would be the procedure for passing these values along to the ISY?  I assume I would have to change config files in Nodelink and/or the ISY to use the modified values/variables instead of the unmodified AIP-x values from the WebControl board?

 

Thanks to both UDI for 5.0 and IOGuy for the Nodelink program - I'm just starting to grasp the potential of these.

 

John

[larryllix]

Is it possible to do “arithmetic” in Nodelink on the analog input values from a WebControl 8 board? My situation is a well pump supplied residential water system where I would like to monitor the system pressure. The pressure gauge I'm using outputs a 4-20mA analog signal, which I will convert to a 0-10V analog signal with an intermediate C-to-V converter board, which I then want to pass along to my ISY  via  Nodelink.  I understand that the WebControl 8 analog outputs are integer only and can range from 0 to 1023 in value.   If  possible I would like to convert the 0 to 1023 values to 0 to ~100, for example by dividing them by 10 and calibrating them to psi values. Is it possible to do this in Nodelink?  If so, what would be the procedure for passing these values along to the ISY?  I assume I would have to change config files in Nodelink and/or the ISY to use the modified values/variables instead of the unmodified AIP-x values from the WebControl board?

 

Thanks to both UDI for 5.0 and IOGuy for the Nodelink program - I'm just starting to grasp the potential of these.

 

John

There are various ways to do this.

 

I don't use NodeLink for my WC8. I use the ISY REST interface and just stuff them into ISY state variables straight from WC8 network interface.

 

WC8 uses all 32 bit variables so you could scale them to whatever value you want I WC8,  send them to ISY. Then ISY can  add decimals into the value by transferring to another register, if need be. This is how I handle my temperature inputs with 0.1C resolution accuracy.

 

I would just send them raw to ISY and let ISY scale them to 100.0%.

 

If

    input is not -1

Then

    set $variable = input <==== use integer variable so not to trigger slave programs

    $variable *=100

    $variable /=1024

    set $sPercentVar = $variable  <---- now transfer into State variable for triggering programs

Else

  --

[io_guy]

Currently not supported in NodeLink.  With WCLink I used to have support for specific AI temperate sensors (LM34 and LM35).  I ditched this in NodeLink since it was so specific.

 

In a future NodeLink version I can add support for AI Scaling and Offset.

[apostolakisl]

I'm with Larry on this.  There is no need for any intermediary when sending values from WC8 to ISY.  WC8 has the webset function where you can directly post values to ISY.  You can manipulate the values in WC8 before sending to ISY if you like, or do the math after they are in ISY.  I would do the math in WC8 myself.  You can write PLC code in WC8 to rescale the value and then post to ISY either on the basis of every x amount of time or by the value changing by x amount.

 

The PLC code below will first rescale 0-1023 to 0-100 and save it in ram1.  The second subroutine will check to see if the current value in ram1 is the same as the previous version (ram2), if it is different, it will call the webset url1.  You need to configure url1 with the ISY REST language.

 

If it were me, I would first install the system and then see what the AIP1 values are for several different psi's and then create an equation to convert the aip directly to psi in wc8.

 

START

CALLSUB SCALE

CALLSUB ISY

END

 

SCALE:

MUL AIP1 100 RAM1

DIV RAM1 1023 RAM1

RET

 

ISY:

TSTEQ RAM1 RAM2

RET

SET RAM2 RAM1

WEBSET URL1 RAM1

RET

 

url languange

first column you put the IP of ISY, nothing more needed if you are on the same lan (ie 192.168.1.10)

second column you put the rest code, (ie /rest/vars/set/2/25/ would set state variable 25 to whatever RAM1 is).  

3rd column you put your username:password into a base 64 converter and then put it in there.  This website does it https://www.base64encode.org/

[Toddimus]

...

If

    input is not -1

Then

    set $variable = input <==== use integer variable so not to trigger slave programs

    $variable *=100

    $variable /=1024

    set $sPercentVar = $variable  <---- now transfer into State variable for triggering programs

Else

  --

Larry, you beat me to it.  I was about to write the same thing.  I would make one change and add another note:

 

• divide by 1023 instead of 1024 -- Since the output range is 0-1023 the max possible value when you divide by 1024 is 100*1023/1024=99.9 so you'd technically never get to 100%
• make sure $variable and $sPercentVar are both configured as floats with at least 0.1 resolution

[larryllix]

 

Larry, you beat me to it.  I was about to write the same thing.  I would make one change and add another note:

 

• divide by 1023 instead of 1024 -- Since the output range is 0-1023 the max possible value when you divide by 1024 is 100*1023/1024=99.9 so you'd technically never get to 100%
• make sure $variable and $sPercentVar are both configured as floats with at least 0.1 resolution

 

Very observant.

 

We always used 1024 for our Scada system analogues but 100% wasn't acheiveable

 

After years we changed again to calibrate FS analogue quantities to 1022 to demonstrate we were not saturated (pinned) at the top of the digital value.  Small errrors.

[Toddimus]

One of my engineer buddies likes to call the difference "mice nuts".    Doesn't matter in the end. 

Actually, your suggestion of using 1022 to divide instead isn't a bad one at all.  That way, if you ever did get a full scale of 1023 and it stayed there, it might be an indication of a problem like a short or open.

[larryllix]

One of my engineer buddies likes to call the difference "mice nuts".    Doesn't matter in the end. 

Actually, your suggestion of using 1022 to divide instead isn't a bad one at all.  That way, if you ever did get a full scale of 1023 and it stayed there, it might be an indication of a problem like a short or open.

On the master Scada system they had  alarm levels assigned for each analogue.

We had a +/- 11 bit system so 2047 was FS.

 

The high level alarm would be set for the limit desired on the electrical grid cable loading. = start switching customers elsewhere.

The high-high alarm would be set to X% higher than that  = start dropping  customers loads.

The ridiculous alarm would be set 2047 = equipment failure

 

Of course our FS primary would be say 800 amperes but the cables were only good for 600 amperes for an hour, for copper, and 120 seconds for aluminum. So we had lots of headroom to establish ridiculous failure indicator values.

 

We did like to supply a scaling factor of 2048 because we felt it may equate to an even binary number, for the math done, on tens of thousands of analogue values every second.  We never did get tech details to establish whether a math co-pro was doing the work and it would become moot. Watt's an ampere or two between friends?

[inovermyhead]

Thanks for all the replies and apologies for my delay in replying (I run a small wildlife genetics company and have been caught up in tasks there!)

 

Yes, I saw that one can use PLC code to do arithmetic or scaling directly in the WC8 - however since it can handle only integer values, it seems like this could result in loss of significant precision.   Correct me if I'm wrong, but I understand that the PLC "DIV" function just returns/assigns the integer portion of the result?  So if AiP1 = 951 or = 959, the integer result of

DIV 10 for either of these values would be 95 in both cases.

 

Doing the scaling and/or any offset directly in the ISY as larryllix or apostolaki suggested would get around this.  However, I was hoping, if something similar could be done in Nodelink, to take advantage of the very elegant - and simple - interface in ISY that Nodelink allows.    Io_guy's indication that this is at least possible in a future release of Nodelink is very encouraging.   I can imagine that AI scaling and offset might useful in a number of situations where one had sensors outputting  analog values (temperature, pressure, wind-speed, etc.) that one wanted to get into ISY via Nodelink.  While waiting for such a function to appear in Nodelink, I will pass the values from the WC8 to ISY and do the arithmetic there.

 

Thanks for all the suggestions.

 

John

[apostolakisl]

Thanks for all the replies and apologies for my delay in replying (I run a small wildlife genetics company and have been caught up in tasks there!)

 

Yes, I saw that one can use PLC code to do arithmetic or scaling directly in the WC8 - however since it can handle only integer values, it seems like this could result in loss of significant precision.   Correct me if I'm wrong, but I understand that the PLC "DIV" function just returns/assigns the integer portion of the result?  So if AiP1 = 951 or = 959, the integer result of

DIV 10 for either of these values would be 95 in both cases.

 

Doing the scaling and/or any offset directly in the ISY as larryllix or apostolaki suggested would get around this.  However, I was hoping, if something similar could be done in Nodelink, to take advantage of the very elegant - and simple - interface in ISY that Nodelink allows.    Io_guy's indication that this is at least possible in a future release of Nodelink is very encouraging.   I can imagine that AI scaling and offset might useful in a number of situations where one had sensors outputting  analog values (temperature, pressure, wind-speed, etc.) that one wanted to get into ISY via Nodelink.  While waiting for such a function to appear in Nodelink, I will pass the values from the WC8 to ISY and do the arithmetic there.

 

Thanks for all the suggestions.

 

John

 

What level of accuracy are you anticipating?  The CAI analog input is probably going to be accurate to around .1 volts and you seem to be looking for .01 volts in your example.  Looking at this in your application of measuring your water pressure, I have to wonder why you would care to know at anything more significant than an integer value.  I have to also wonder what pressure transducer you are using and if it is even capable of anything more accurate than that.  It would be a very expensive pressure transducer to measure in the 0-100 psi range and be accurate to anything more than an integer value.

 

Having said that, both ISY and CAI truncate any fraction when doing division.  In both, you just move the decimal point by multiplying times 10, 100, 1000, or whatever you want to maintain the precision you desire.

 

I consider using a middle man the opposite of elegance.

 

I have measured psi using cai webcontrol and the analog input.  I have used the Freescale transducers that output .2 - 4.8v range and directly connect them to cai.  It works just great.  You may also find that CAI does not measure voltages all the way up to 10v depending on what hardware version you have.

 

http://www.nxp.com/files/sensors/doc/data_sheet/MPX5700.pdf

[larryllix]

Thanks for all the replies and apologies for my delay in replying (I run a small wildlife genetics company and have been caught up in tasks there!)

 

Yes, I saw that one can use PLC code to do arithmetic or scaling directly in the WC8 - however since it can handle only integer values, it seems like this could result in loss of significant precision.   Correct me if I'm wrong, but I understand that the PLC "DIV" function just returns/assigns the integer portion of the result?  So if AiP1 = 951 or = 959, the integer result of

DIV 10 for either of these values would be 95 in both cases.

 

Doing the scaling and/or any offset directly in the ISY as larryllix or apostolaki suggested would get around this.  However, I was hoping, if something similar could be done in Nodelink, to take advantage of the very elegant - and simple - interface in ISY that Nodelink allows.    Io_guy's indication that this is at least possible in a future release of Nodelink is very encouraging.   I can imagine that AI scaling and offset might useful in a number of situations where one had sensors outputting  analog values (temperature, pressure, wind-speed, etc.) that one wanted to get into ISY via Nodelink.  While waiting for such a function to appear in Nodelink, I will pass the values from the WC8 to ISY and do the arithmetic there.

 

Thanks for all the suggestions.

 

John

I came from a world of tens of thousands of analogue inputs that are all shipped as raw binary counts from the transducer inputs as thy are created. No accuracy is lost and every receiving end may translate and massage the values based on their own math massaging abilities. I beleive you will have to massge the data in ISY anyway so will need a landing State variable and a finished / resultant State variable anyway.

 

BTW: To create a rounding algorithm just add half the value of the divisor.

 

Using integer arithmetic:

123456 / 100 = 1234

 

(123456 + 50) / 100  = 1235

[io_guy]

If a person is already running NodeLink I would say it's the better spot.

- No custom code required in the memory-limited CAI board (and also supports older CAI firmware w/o REST)

- Native node integration to the ISY

- No custom programs or variables required to be setup in the ISY

 

In either case, I don't care which way the cat is skinned.  I will be providing scaling functionality in NodeLink, do what you want with it.

[larryllix]

The WC8 boards prior to hardware version 2.2? had no support for the ISY REST interface (as per io_guy above)

 

These can be updated by sending the board back to CAI for reflashing,  but the shipping cost both ways, costs more that the board itself from mid Canada.

 

This is a very generous and useful gift to those early hardware version users of WC8 boards, from io_guy.

 

    ....and he doesn't even charge for shipping either!

[apostolakisl]

I guess I don't care how he skins the cat either.  But unless he has a cai board that is more than I think 3 years old (or more), he will have the webset function.  And the boards that are within the last year or two can be be firmware updated at home.  Copy and paste the code I wrote above into cai and you are pretty much done.  I guess you still have to decide what it is you want ISY to do with the numbers.  If all you are doing is sending notifications, I would do that directly in CAI also.  The only caveat being you need an email server that doesn't require encryption, which is getting harder and harder to come by these days.  While CAI is memory limited, it would require like 10,000 times more code than I just wrote to fill it.

 

Assuming the psi is 0-100 and the voltage is 0-10, you would get accuracy to .1 psi as it is written.  In other words, if the value delivered to isy is 573, then it would be 57.3 psi.  But I would be shocked if you had a transducer that has a tenths place that is actually real.

[larryllix]

<snipped>.  While CAI is memory limited, it would require like 10,000 times more code than I just wrote to fill it.

 

Assuming the psi is 0-100 and the voltage is 0-10, you would get accuracy to .1 psi as it is written.  In other words, if the value delivered to isy is 573, then it would be 57.3 psi.  But I would be shocked if you had a transducer that has a tenths place that is actually real.

Agreed.

To clarify some of that to potential CAI WC8 purchasers / users.

 

The WC8 memory shortage is internal RAM memory that users never see.

Apparently the limited RAM it is shared between 1-wire, Ethernet and other internal driver functions, not the users program space.

 

User program memory is unlimited (exag) to the user for program coding.

 

 

If you do have an older WC8 board NodeLink can be a way to get it out of the junk box and interface it with ISY now..

[inovermyhead]

Apostolaksi - of course you're right; I was over-thinking this.  The pressure sensor I'm planning to use has an accuracy of only 2% at full scale so worrying about truncation of division remainders is immaterial.  Thanks for the (gentle) slap on the side of the head.   It will be connected to a new WC8 (HW rev 2.3. so I can use either the webset function or Nodelink.  I'm a noob at this so I will probably try both as a way of learning how they each work.  Thanks for the help

 

John

[larryllix]

Apostolaksi - of course you're right; I was over-thinking this.  The pressure sensor I'm planning to use has an accuracy of only 2% at full scale so worrying about truncation of division remainders is immaterial.  Thanks for the (gentle) slap on the side of the head.   It will be connected to a new WC8 (HW rev 2.3. so I can use either the webset function or Nodelink.  I'm a noob at this so I will probably try both as a way of learning how they each work.  Thanks for the help

 

John

I think using NodeLink could make some values bidirectional, also. io_guy will have to confirm that.

[apostolakisl]

Agreed.

To clarify some of that to potential CAI WC8 purchasers / users.

 

The WC8 memory shortage is internal RAM memory that users never see.

Apparently the limited RAM it is shared between 1-wire, Ethernet and other internal driver functions, not the users program space.

 

User program memory is unlimited (exag) to the user for program coding.

 

 

If you do have an older WC8 board NodeLink can be a way to get it out of the junk box and interface it with ISY now..

 

I was not aware of this memory issue.  I certainly am aware of one-wire complaints and perhaps this is the reason.  From a PLC program memory perspective, I have some programs that are several hundred lines long, which seems like a lot of code for this device.  I don't really know when I would hit the max size of a plc program but doubt I ever will since, like I said, a few hundred lines is kind of a lot in the WC8 board world.

[apostolakisl]

Apostolaksi - of course you're right; I was over-thinking this.  The pressure sensor I'm planning to use has an accuracy of only 2% at full scale so worrying about truncation of division remainders is immaterial.  Thanks for the (gentle) slap on the side of the head.   It will be connected to a new WC8 (HW rev 2.3. so I can use either the webset function or Nodelink.  I'm a noob at this so I will probably try both as a way of learning how they each work.  Thanks for the help

 

John

 

And along those same lines, if you were to post values to ISY using the above program, you would probably find that it is post like 100 times per second.  I would suggest truncating all decimal (dividing the above by 10) or you will overwhelm the system with useless data.  You will just have to see for yourself how steady your pressure reading is, even posting with single digit changes in psi may be too sensitive and result in a lot of useless rest commands being sent to ISY.  You can get fancy and build some hysteresis into your code, which actually isn't that hard to do and can help with only posting data that has real meaning.  Or you could write the code to post on a time basis, say once every 5 seconds.  You can also do a running average of sorts.  I haven't really found a good way to do true running averages on WC8, but it is easy to do take blocks of readings and average them.  Like take 100 readings, get the average, then do another 100 readings and average them and so on.  This would cancel out most of the "jitter" you get when reading the analog voltage input.

[larryllix]

I do running averages for my wind speed average measurements.

 

Average_LAST x 19 + newWindSpeed

------------------------------------------------  =  Average_NEW

                    20

 

This  gives a long slow average ramp up and down. For a temperature you could swap say...3 for the 19, and 4 for the 20 in the formula.

 

In an older thread, I posted PLC code to time slice jobs up so that different values get stuffed into ISY once every 15 seconds and each value gets it's turn on a one second slice basis. This ensures not to bog down ISY or the Ethernet port on the WC8, which saturates and throws away anything over 4 sends due to the RAM shortage.

 

If you just have one or two temperatures to send to ISY a simple delay in the loop works just fine.

 

 

@Apostolakisl: The 1-wire interface would bog down and then WC8 didn't know what to do, without unique memory spots, couldn't switch tasks, so just rebooted constantly. This sends garbage value glitches on running averages or values that need to be continuous through a reboot.

[apostolakisl]

I do running averages for my wind speed average measurements.

 

Average_LAST x 19 + newWindSpeed

------------------------------------------------  =  Average_NEW

                    20

 

This  gives a long slow average ramp up and down. For a temperature you could swap say...3 for the 19, and 4 for the 20 in the formula.

 

In an older thread, I posted PLC code to time slice jobs up so that different values get stuffed into ISY once every 15 seconds and each value gets it's turn on a one second slice basis. This ensures not to bog down ISY or the Ethernet port on the WC8, which saturates and throws away anything over 4 sends due to the RAM shortage.

 

If you just have one or two temperatures to send to ISY a simple delay in the loop works just fine.

 

 

@Apostolakisl: The 1-wire interface would bog down and then WC8 didn't know what to do, without unique memory spots, couldn't switch tasks, so just rebooted constantly. This sends garbage value glitches on running averages or values that need to be continuous through a reboot.

 

Yes, this sounds like the 1-wire issues I have heard.  Never paid a lot of attention since I pretty much don't use 1-wire with any of my boards.

 

The trouble with CAI and running averages is that you don't have very many memory locations to store the numbers.  You have 8 rams and 8 vars.  If you have small numbers you can split those 32 bit memory locations into 16 or 8 bit locations and get more, but it gets to be convluted.  It just depends on how many values your running average needs to contain to do what you want.

 

Doing blocks can all be done with just a single memory location.  You just run a loop say, 100 times each time adding the current value then divide by 100 after the last loop, then start over.

 

There are other tricks you can do.  Like take the difference between your current established value and adjust it by a fraction of the difference between it and your current aip value.

[larryllix]

Yes, this sounds like the 1-wire issues I have heard.  Never paid a lot of attention since I pretty much don't use 1-wire with any of my boards.

 

The trouble with CAI and running averages is that you don't have very many memory locations to store the numbers.  You have 8 rams and 8 vars.  If you have small numbers you can split those 32 bit memory locations into 16 or 8 bit locations and get more, but it gets to be convluted.  It just depends on how many values your running average needs to contain to do what you want.

 

Doing blocks can all be done with just a single memory location.  You just run a loop say, 100 times each time adding the current value then divide by 100 after the last loop, then start over.

 

There are other tricks you can do.  Like take the difference between your current established value and adjust it by a fraction of the difference between it and your current aip value.

The part I really don't like is he numeric labelled RAM, ROM memory locations.

I would like to see an editor that can do string substitutions so that we could label the memory locations with sane labels. This would be totally in the editor on your PC and not affect the WC8.

 

     ADD RAM1 RAM2 RAM3

could then read

     ADD  Last  Input  New

 

Long programs can get hard to understand what you did. A separate editor can be used but the double dump process can be a PITA for hacking out code when new to the instruction set.

 

Other than those some micro-shortcomings, the thing is a cute box to do a job, and the PLC language makes me feel right at home from assembler code writing days. I really enjoyed it.

[apostolakisl]

The part I really don't like is he numeric labelled RAM, ROM memory locations.

I would like to see an editor that can do string substitutions so that we could label the memory locations with sane labels. This would be totally in the editor on your PC and not affect the WC8.

 

     ADD RAM1 RAM2 RAM3

could then read

     ADD  Last  Input  New

 

Long programs can get hard to understand what you did. A separate editor can be used but the double dump process can be a PITA for hacking out code when new to the instruction set.

 

Other than those some micro-shortcomings, the thing is a cute box to do a job, and the PLC language makes me feel right at home from assembler code writing days. I really enjoyed it.

 

I write my plc in ms word.  You can annotate and substitute words for things like ram1.  Before loading into wc8, you run find/replace all command for rams and vars and the annotations don't copy when you do a copy all command during the transfer.  The thing about ram and var values is that you end up reusing the same ones over and over for different purposes, so you wouldn't want to be limited by a single name substitution.

[inovermyhead]

Apologies for reviving an old thread, but I'm still having trouble scaling analogue inputs from a WC8 in Nodelink.  The inputs are working fine, but when I  put any values in the "scale" or "offset" boxes for the analog inputs and press the "set" button, I get the following error message: "Error: Conversion from string "" to type 'Integer' is not valid".  What am I doing wrong or missing?   Thanks

 

John

[inovermyhead]

Oops; forgot the other useful details: ISY firmware & UI v5.0.4, WC8 w/ v03.03.27 and Nodelink sever v0.6.8, with latest zip file.

 

John