Ausman

MVP 2016
  • Content count

    287
  • Joined

  • Last visited

  • Days Won

    19

Ausman last won the day on March 19

Ausman had the most liked content!

Community Reputation

44 Excellent

1 Follower

About Ausman

  • Rank
    UniGuru

Profile Information

  • Gender
    Not Telling
  • Location
    Orstralia
  • Interests
    Love/Hate waking up with a solution to a problem. Thanks brain....for not sleeping properly!

Recent Profile Visitors

3,005 profile views
  1. Multiple options is a different kettle of fish. However, the basics are the same. Because MIs can be used in compares, you can set things up based on answers to HMI questions moving numbers into the relevant MIs. How many in total? Move that answer into the total count MI. How many before I need to do the first change? Move that into the MI controlling the first compare set. How much to lower the head each time? That goes in another MI etc etc. There will be other methods, but this is likely easiest for you at present if you are talking variables on a range of things all the time. cheers, Aus
  2. Hi all, I've got a situation where I am using hold-down operations on various keys. The 130 reacts correctly to doing single or multiple hold-downs if doing them manually. But is it possible to do this using R Access? I can't find any way to do it, and I've experimented a fair bit. If it is feasible, could it please be incorporated in the future? I have various "button-hold" operations that work fine manually and are often far better suited to the particular job than other methods available, but I am forced to fundamentally change my operations to more complex methods as I need to be able to use RA as if I was onsite. cheers, Aus
  3. Hi Visco, First thought is to set up a counter that uses compares to control the operations based on the count it has reached by adding 1 each operation. You can then manipulate the count to easily adjust/reset if necessary. cheers, Aus
  4. Thanks Alex, I interpreted this as "you don't have this in the ladder at all" which made me ask the question. I was wondering how it would then run! And as Hot says, why does it show up in Optimise? Finally, don't forget that for even better accuracy use the 1.25mS when you can. cheers, Aus
  5. Hi Vamalgise, If it's a good brand of valve, it should work ok straight away. I'd also re-check the following: 1). The wiring is into the correct terminals on the AI4AO2. It is very easy to go in the wrong hole! Expecially in an awkward location. 2). You haven't got the input and output lines from the actuator/modulator on the valve mixed up? 3). Everything within your program, and hardware setup is matched to using 0-10V? cheers, Aus
  6. Hi Alex, I'm a bit confused now. Have you looked at my pumpexample2.vlp above? The interrupt is done as specced by the Help files, and works fine. Is there another way they should be done? cheers, Aus
  7. Hi all, I've been intrigued with this topic, as it covers ground I've had issues with now and then. I always break nets up more than probably necessary. But it does enable clearer understanding of flow when I revisit something. But Alex, you are essentially saying that if you have a host of transitional contact(s) usage in a program, put them in the very first nets running MBs. And then use the MBs instead. This is shown in the help files as a means to reduce the amount of execution time/usage, but nowhere does it actually recommend this as the method to ensure correct operation throughout the scan. There is a difference and I think it should be made clear. cheers, Aus
  8. Re optimise, don't know why that shows. Bug--Saragini? cheers, Aus
  9. Well, compile returns no errors at my end, under 9.8.31. And I suggest you actually run it to learn the capabilities. The layout should remain as is, see the help files previously mentioned. As far as I know, anything with a colour screen is Enhanced. cheers, Aus
  10. To clarify things that are being misinterpreted, I experimented and have my example of how to do it. This was run on a V130 with the latest firmware. It is the basics of everything you would need, and really is very simple once I got there. It gives the "immediate" flow rate between the last sense and the one before that, like I have previously suggested. I used the 2.5ms count for simplicity and the ability to run on older units. Edit: oops, wrong number in the vlp, changed it to correct. cheers, Aus Pumpexample2.vlp
  11. So is the pump centrifugal , or positive displacement? If you have a centrifugal running at zero flow you've got a problem regardless...say goodbye to the seal in no time. If they're running dry it's quickly ta ta, but if they are running full without output then they get cooked. Positive displacement not so much. For all the other things you want to monitor, it can still all come back to whether the pump is being called for and what the flow is. You say it is normally 60gpm, so the real question is what causes the variations from this normal rate, and how much does it normally vary. Those are the crucial questions and answers. Anything outside those amounts is an error. And further to the use of the interrupt, I was meaning for it only to be used to advance the counter by 1 every interrupt cycle. It is doing nothing else, the normal program does the rest of the calculations. You could likely get more accuracy by involving IO immediate updates in the main program as well, but it may not make that much of a difference. The program looks simple so isn't going to be too big and hence a long scan time. cheers, Aus
  12. So you don't have a way of knowing if the flow is meant to be going or not? The turbine is the only thing? In that case you would still have a high limit on the count that if exceeded still got reset to 0, and your result would read "currently less than .01 GPM" or whatever that high limit = minimum flow maths result is. The main method is still the same, when the turbine's pulse goes high the count is stored and then reset to 0. By applying correct maths on the stored count you get the correct current GPM if it trips over before the maximum count/minimum flow rate is reached. cheers, Aus
  13. And you don't need the counter to be run via a latch. Have it just banging away all the time the flowmeter is meant to be running. You then have upper and lower limits on the count that are your alarm points. In some instances, I also build in X numbers of self-correction, in case of a gliche. ie it goes outside the alarm points, alarm counter gets one addition, counter gets reset to 0, process repeats X times. If it turns out to be a temporary thing, I store the error date/time and reset the X error count to 0. If it goes over X, it is a real issue and a stop/warning is needed. There are myriad variations on this concept to suit the particular job. It all comes under the guise of you initially write a program in the logical way, then look at it later and realise you can simplify/improve things all over the place! Many, many times I have uttered words like "why didn't I do that in the first place....what a dummy!" cheers, Aus
  14. Unless the turbine is a very big diameter and the sense is minute in it's arc, I don't think you will have problems using normal DIs on such a slow Hz rate. I wouldn't be bothering with HSC, but the only way to know for sure is to try it using the plc to measure On time, which wouldn't be that hard to set up. (But my impression of you is I'd bet you have an oscilloscope handy!) The following paragraph is helpful for this, too. As for the counter, have a squiz at the 1.25 & 2.5mS Interrupt Routine descriptions, found in Interrupt in Index. This should easily give you enough accuracy for what I was suggesting. And the number of "lobes"/"magnets"/"little men shouting "OYYY" as they go past" increase?? "Haven't examined the mechanics"?? Huh! What have you been doing all this time? All things relating to the forum must be acted on immediately! Cara said so. cheers, Aus