AzeoTech

Administrators
  • Content Count

    5,899
  • Joined

  • Last visited

Community Reputation

0 Neutral

2 Followers

About AzeoTech

  • Rank
    Guru

Recent Profile Visitors

51,114 profile views
  1. AzeoTech

    Rounding functions

    You just add 0.5 and do floor(). So for the nearest integer it is just: floor(value + 0.5)
  2. OK, so the LabJack is going to give DAQFactory a voltage reading. It looks like your sensor is, as you said, a 0-1.6 bar with an output range of 4-20mA. That means that at 0 bar it will likely output 4mA, and at 1.6 bar it will output 20mA. The problem is that LabJack's don't read mA readings without a resistor to convert it to a voltage, and that conversion factor is determined by which resistor you choose, as defined by Ohms law (V = IR). So if you used a 250 ohm resistor then 20mA will give you 5V. When looking at the numbers you provided, I see two things: 1) P2 is pegged at 5V which means that you have a wiring problem, possibly a resistor that is too big. 2) your two point cal is way to close. 682 to 688 isn't much of a span. You will get a very inaccurate slope doing this. You should instead choose, say, 682 and 0. But before you can do the two point cal, you need to address P2 and why it shows 5V. If both inputs have the same resistor, you should get about the same voltage from both sensors.
  3. OK, the "unit" setting in graphs and other components are just a label. They don't actually change the value to that unit. DAQFactory has no idea what units 11.64 and 11.98 are in. If you are using a 0-20mA DAQ device than it may be in mA. You need to figure this out first, or you need to do a two point calibration by taking the reading in DAQFactory and the actual reading in your system at two different pressures, ideally as far apart as possible. Then you can calculate the slope/intercept to convert between whatever units you are seeing in DAQFactory and pressure. Note that this is not a DAQFactory thing. You would have to do this with any software tool as the software has no idea what you have wired into the DAQ and only gets a number from DAQ hardware.
  4. Sorry, but that didn't clear it up. What is the raw reading when you have 0.609 bar? The DAQ device you are using is likely not outputting values in engineering units (bar, psi, etc) but more likely as either volts, mA, or in a value from 0 to some full scale value dependent on the DAQ, usually either 4091 or 65535.
  5. Does the channel currently read a number from 0 to 20? Or does it read a number from, say, 0 to 5? As an example, if it reads 0 to 20 and 4 corresponds to 0 bar, and 20 corresponds to 1.6 bar then the Conversion would be: Value * 1.6 / 20 Basically, when 0 = 0, the math is super simple. It is just Value * engineering max / raw reading max.
  6. AzeoTech

    pO2 and PID

    What you are talking about is not really PID. PID really only works with analog outputs, or with pulse width modulated digitals (which are effectively an analog out). You could maybe make it work with PWM, but it would be severe overkill and you'd waste a lot of time trying to tune it. In your case, you just need a thermostatic type control. To do so, go to the event on your pO2 input channel. Then add some code, something like this (assuming "relay" is the name of your relay channel): if (relay[0] && (pO2[0] == 0)) relay = 0 endif if (!relay[0] && (pO2[0] > 0.3)) relay = 1 endif Of course you can set the 0.3 to something smaller to ensure you don't exceed 0.3. I should mention here that I rarely ever use PID for anything slow moving. It is much simpler to use thermostatic type control, possibly with a little proportional output (so a P loop instead of a PI or PID).
  7. 1st, I would look for why a blank screen takes 300ms to draw. That tells me you have some CPU intensive scripts. 2nd, though this may not be the case here, Mouse Up is not always received by DAQFactory. For example, if you Mouse Down on something, then move your cursor outside of the DAQFactory window before releasing the mouse button, the Mouse Up message may not be received. 3rd, we have found an issue with some object oriented blocking that can cause things to run slow. Basically if you call myObject.memberFunc1() which takes a while (for example doing I/O) it will block access to that object. Then if somewhere else, say in the UI, you try and call myObject.memberFunc2(), or even access a variable: myObject.memberVariable, it will have to wait until the first function is complete. This may be the source of your slowness.
  8. Hate when that happens. That is why I always tell people to put a 0 in front of decimals that are < 1. So: 0.1 NOT .1 It is too easy to lose the ., especially when handwritten. Curiously over the years I have found that engineers tend to use .1, while scientists use 0.1.
  9. I would have to look at the source and then make an educated guess. A simpler way is to simply try deleting these components and see how much it improves the screen draw time. If you are missing clicks your screen draw time must be very long so it should be very obvious what is causing it if you just slowly start deleting components until it speeds up.
  10. Yes, almost certainly. Windows only processes messages one at a time within an app as it is all done from the primary thread. If your screen is taking a long time to draw, then it will be sluggish to process other things like mouse clicks. Mouse move for the cursor is different and won't be sluggish. Any mouse move processing in DAQFactory will be if you have slow pages, but the cursor will still move quickly. I would try and figure out why the page is so slow to refresh. I'd just look at the refresh time and start deleting components. My guess is that you have one, or maybe a few, components that are taking all the time. Once you figure that out you can look into why and fix it.
  11. Yeah, it sounds like the screen draw is tying things up. The click message will be delayed while the paint message is being processed. There isn't a built in way to see redraw times in Runtime. You can see it in development mode in the status bar. One option in runtime would be to put a component on the bottom (Order -> Move to Bottom) and put in its OnPaint event: global startPaintTime = systime() Then create another component that you put at the top (Order->Move to top), and in its OnPaint event put: global totalPaintTime = systime() - startPaintTime Then you can use a variable value component to display the totalPaintTime variable. This only works on non-overlaid pages.
  12. You don't need addvalue() if you are using a conversion. Just create a conversion: Value - loadcellZero Then apply that conversion to your LoadCell channel, by selecting it from the list. Now your LoadCell channel will display zeroed values once you zero it. Put: global loadcellZero = 0 in a sequence marked Auto-Start so when the system loads it will initialize the zero value to nothing. Then create a button to re-zero with a Quick Sequence action: loadCellZero = LoadCell[0] + loadCellZero That is it. Don't use addValue. Don't put the channel name in the conversion. Also don't put an = sign in a conversion. A conversion is an expression, not a statement.
  13. First, I would not use V channels. They are a left over from a very long time ago that remain because customers still like them for some things. However, they do not work directly with Logging Sets, which is why you aren't able to log them. Instead you should either create a Test channel and stuff it with your converted data as you described, or use a Conversion to convert the data as it comes in. Which you use really depends on whether you need to still see the raw, unconverted data. If you do, then you'll need two places for data, one for raw (the actual I/O channel) and one for the converted data (the Test channel). If not, then you can just apply a conversion to the actual I/O channel. The tricky part if you are using a Conversion and single channel is that when you zero, you have to back out the existing zero value. So for example, if your conversion is: Value - zeroValue where zeroValue is some global variable that is initialized to 0 on startup. If you then have a Zero button that basically takes the current raw value and make it read 0 (like a Tare), then you have to remember to back out the existing zeroValue first. So if the channel the above conversion is applied to is called LoadCell, the zero button would be: zeroValue = LoadCell[0] + zeroValue It would NOT be: zeroValue = LoadCell[0] because LoadCell[0] has been shifted based on the current value of zeroValue.
  14. First, what release of DAQFactory are you using? 2nd: the issue is probably related to the capture() functions. What I would probably do is simply duplicate the page, and make it so capture() works on the duplicate and that you never actually view the duplicate. That way, capture() is working on one copy, and local viewing is using the other and there is no conflict. As to the feeders page, my guess is that the time width on the bottom axis is throwing it, that your feed1_ca_voltage has good time, but the others are skewed somehow, probably due to feeder2_importKW. Try changing the bottom axis, unchecking Time Width, and setting the scale from to "systime()-48600" and scale to to "systime()" If that fixes it, then that is the problem and you can either leave it, or figure out what is skewing the time.
  15. There is nothing wrong with that line. It'd probably be best if you emailed us the .ctl doc. My guess is you are looking in the wrong place. Or you have some weird invisible character in the line, in which case, delete the line and retype it. I get this sort of thing in other development environments but have actually never seen it happen in DAQFactory.