Jump to content

Ausman

MVP 2023
  • Posts

    2,593
  • Joined

  • Last visited

  • Days Won

    175

Everything posted by Ausman

  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
  15. Hi Hot, could you add some more "lobes" to the turbine? Might be simpler than you think. Is it Hall or something else? If I've read you right, are you doing the maths backwards? Think laterally and set it up based on a quick counter that has the count stored and reset to 0 each pulse. Then do the instantaneous maths on the stored count, and that is either close to/exactly current rate. Don't compare it to a fixed time. I've mentioned before that I think counters are an under-utilised item. Often they outperform timers in a myriad of ways. cheers, Aus
  16. Thanks Saragini, just to clarify, it doesn't flicker "on it's own", the flicker is when you move the mouse tiny amounts over the labels. I only have 1 monitor on this computer. One thing I do have that might be unusual is that I use Classic shell http://www.classicshell.net/ This is the only way I could get around some of the Win7 annoyances, ( folder behaviour in particular, edit: another program does this, oops) and works well. As I have said, I am only learning unilogic by program fiddling following posts on the forum. So I only have it on this one computer. Give me a few days and I'll try things on another puter and see what happens. cheers and thanks, Aus
  17. Hi again all, can the creators please explain what this .exe does and when, and why it sometimes persists after the program closes. It is not running as a service, appears to be initiated on start of Unilogic, sometimes starting a number of instances on the same port each opening (but different each time), and then perhaps retaining one after close. Behaviour doesn't seem to be consistent each time. cheers. Aus
  18. Yes to Flex's comment. If I click the link.jpg I get the result.jpg cheers, Aus
  19. Thanks Saragini, Firstly, +1 to Joe's comments about forum interaction. Secondly, it is during right clicking on modules. The blackonblack.jpg shows the black writing. No. 2 shows it highlighting to white if the mouse hovers, but this change to white is very erratic, changing frequently/flickering as you move the mouse tiny amounts in the area where the highlighting should be constant. This is on my main system which is still 7 32 Home Premium. It is only minor, but I figure it's not that hard to change to make things a bit nicer for the user. And again sorry to Mikey for deviating this thread. cheers, Aus
  20. Well....everything it had. Sometimes I remember a solution I stumbled upon in the past on the old forum, and want to revisit it. At present it would seem that the old forum is completely inaccessible. It came up because I was trying to chase the DST solution I mentioned elsewhere, that I couldn't find...maybe it was the old forum. cheers, Aus
  21. Hi all, is anyone else having trouble getting to the old forum via the link: http://www.unitronics.com/forum_old/ Was trying to look up an old reference and although the forum header says it is there, it brings up an error. cheers, Aus
  22. Wondering if you could just have the plc monitor & provide overall "control", but use a simple direct control loop to do the fast work? Or alternatively some sort of converter which changes your position sensing on the actuator to a High Speed Frequency Output, which might make things possible. A quick goggles found this: http://www.redlion.net/product/analog-frequency-converter-module cheers, Aus
  23. Thanks Saragini, that makes sense. How did you arrive at the conclusion? Just knowing what they all do? And whilst I'm about it, although going off topic, why does HWare module manipulation pop up black writing on a black background? I know it changes to white if you hover, but it seems a bit dumb. cheers, Aus
  24. Yes....sorry Cara, it sort of evolved into a discussion about the need for such a thing across all Unitronics types. But in my case I am particularly talking about Visilogic. Given that DST is a common thing worldwide, yet Unitronics has no innate means of implementing it without user coding, is a bit of an oversight in my opinion. I have worked with simple RTC timers that allow me to set it up with a few button pushes, so a far more complex PLC should also have the means to make it easy. cheers, Aus
×
×
  • Create New...