Ausman

Thanks Joe! Didn't know that one!!! LSNED! cheers, Aus

Reading that manual causes me to ask what model in that series are you using? cheers, Aus

More information needed in the form of screenshots of setup, program etc. You are essentially telling us "My car won't start!" cheers, Aus

Hi Mat, my understanding of what you are saying is that you think the dialog locations are kept as part of a .vlp? You were working on the program on a multi-monitor and now you are on a different computer (laptop) some things are seemingly placed incorrectly indicating that locations are saved within the file? I don't recall this happening in my instances at all, but I cannot play with this for at least another few days, others may be able to check this soon. I recall that sometimes I have instances where I have to swap monitors onto the other connection for some things to work properly....it often makes no sense but it works. From memory this has been where the MB has a standard fitment of a 1 x vga and 1 x dvi port. cheers, Aus

Flex has shown the actual numbers involved in the Linz as suggested. There is also another approach to your issue that would give you better resolution at the 16 bit side, depending on whether the pressure sensor is true analogue. Change the way you are hooking things up and use a "4-20ma/0-10V/whatever it is working with" splitter to effectively turn your output from the sensor into 2 outputs that can go directly into both plcs' inputs. Any net search will bring up myriad devices available to do this. cheers, Aus

Haven't had a chance to look at your program in depth. Unican can get very confusing when specifying Vectors involved in any structs. Visilogic doesn't really help at all with the way it names things, and I have touched on this in the past. Whenever I construct a more complex series of Structs, I lay it all out in an excel sheet, with it clearly in front of me what goes where. Any vector in use, I label the entire block of all the MIs involved in a way I can easily identify, eg MI1000 = VectStr1OUT-0, MI1001 = VectStr1OUT-1, etc. .......and MI1100 = VectStr1IN-0 etc. I do this even if I'm not using all the 16 MIs, thus keeping the space free for possible future use. This way you ensure that you never accidentally use an MI that is involved in a vector, because it appears free but is is actually in use in a "hidden" way. I also use a time based trigger to activate the unican send. But you can't make it too small.....I have had issues with wanting to do things too fast, most of the time SB13 is easy and good enough. cheers, Aus

72% doesn't make sense, have you assigned everything? But I agree, it looks like you are under. In theory it is (16% x 4) + 12% = 76% Perhaps you've already got incorrectly assigned I/Os that you've missed somewhere, that the compiler is picking up? Joe T will likely have more wisdom on this. cheers, Aus

Because you are applying incorrectly sequenced maths to separate totals, resulting in different amounts? cheers, Aus

I think that you're getting into being over the I/O limit. When you enter your operands into the Hardware config window, there is a "calculator" at the bottom which shows capacity in use and space left. For example, a fully utilised ATC8 uses 16% on an RC1. I didn't run through your setup completely because it would have taken time to do it all. It can be confusing because you actually have to assign everything for the count to be "checkable". If you don't assign everything, it will let you add things over the innate limit and you will think it is ok. This old topic might help: cheers, Aus

Don't forget the valve. Clamping 24dc is easy, and the best method is the diodes mentioned by Walker and Joe at the end of that topic. But anything in the enclosure that has a coil of some sort needs suppression. And it would be interesting to measure the line dip and length when the motor starts. You are going to a lot of trouble, but your first actions may not necessarily be the cure. cheers, Aus

Hi Green, I think what you are wanting is under Math/Linearization. If you want to see how it works, have a look at my calculator here: Be aware, though, that you are sort of working backwards going from 10 bit to 16. You are always going to have number jumps, that is the only way the maths can work. cheers, Aus

Hi Orso, have you got a small delay in between the various buffer reads you are doing? Given that you are working with modbus, you will likely need a few scans at least, if not more, for the buffer to be correct for what you want to do. cheers, Aus

And after you send it, you could always stick to the old version and use Version Swapper......that's what it's for. New and Wonderful is not necessarily needed, or indeed useful, a lot of the time. If it ain't broke, don't fix it. cheers, Aus

Going on your diagram, that is a motor somewhere around 3kw. Each time the contactor kicks in, this would be creating quite a dip on the volts feeding the power supply to the plc, as they are on the same line. Depending on both the mains power supply setup, and the 24v dc unit itself, this may or may not be an issue. And I'm assuming the motor is external. Anything that is an inductive can.......will (!) cause issues to plcs. The topic Joe refers to ( http://forum.unitronics.com/index.php?/topic/2735-flyback-diode/ ) is essential reading. One only has to power an unprotected 24v dc relay on and off, and then do it again with a clamp and you can actually hear the difference. It sounds so much happier. The principle of collapsing fields making very high voltage is the way your car puts a spark across the spark plugs, so you can imagine such things being damaging to sensitive devices if not controlled. So as Joe says, I'd definitely be clamping everything, the contactor, valve and anything else that might be hidden. Also, it is not unheard of for end users to add in inductive (and other) devices that play havoc with a normally perfect system. Denial, denial, damn useless machine, and then when the plc person visits the site they discover the real reason! cheers, Aus

Dumb question as I'm not sure of any involvement in the process, but has the RTC on the PLC been checked (and set correctly) after the O/S upgrade? cheers, Aus

I can't understand how the simple fact of getting married would interfere with forum participation. 😉 cheers, Aus

There's not really enough information here. It seems that you want to supervise a digital output by reading the output's voltage (through a voltage divider??) and reading that back into an analogue? Huh? It also seems to me that part of your problem is the way things react to faults. They specifically act that way on purpose. Short a power supply and it won't reset until a power cycle. etc etc. cheers, Aus

And note the edit after this original lot which I've changed to italics!! And as well as Joe's comment, and perhaps related to your issue, your descriptions describe the flow meter 1 output as M/Hr. If it is indeed giving you an instant reading of cubic metres per hour, then why is there a 3600 involved in your calculations? If the reading is M³/Hr, then even though you are doing it once a second you don't want to be multiplying it by 3600 to turn it into an hourly rate. It already is. And it might result in the different readings. Edit additions: You know how some mornings all your brain cells are firing off fantastically and that horrible problem programming issue gets resolved in a flash? Well...this morning wasn't one of them ( ⚠️ ) and I wrote some odd things! However, this question tumbled around in my head on and off all day, and I realised that I was partly on the right track....I probably hadn't had enough coffee. And it was a Saturday morning. And it was hot. And anything else I can use as an excuse. It needs to be broken down into the sequence. The sequence you have is, to my eye, incorrect. The M³/hr is read every second, that reading needs to be divided by 3600, the result of this division is added to both the full accumulated total and your weekly total, and nothing further needs to be done to it. At your weekly button push, the weekly total is simply reset to 0 and that count starts again. You will also have to ensure that the system's operands in use can cope with the different number ranges needed. Me writing this now will (hopefully) let my brain sleep properly tonight! cheers, Aus

I see that Joe has had time to have a good look at your programs and offered solutions. Hopefully you'll be well on the way to success, so thanks Joe! Again! cheers, Aus

I hear what you are saying Barry, but isn't your scenario more a "change things by having correct programming of the plc in the first place" type of thing? Anyone on a mill floor should not be having access to the program that runs the plc, they should only have access to whatever is on the HMI. If they can't change things sufficiently using that, then the user program is not correct and should be modified to suit all the needs. cheers, Aus

I'd initially check that you have power properly onto the AO6, and that all the connectors b/n the various modules are correctly in place. What happens if you move the modules around, or progressively connect them. Personally I've have put the AO6 at the end of the line. The other thing may be that you are wanting to do things too fast. The modules take time to collect info. If the first suggestions don't do anything, consider changing your unican comms to space it out a bit. cheers, Aus

OK. Let's break this down to the separate things needed to achieve this. 1). Push a button. 2). Count a period of time that the button is pushed for. 3). At the end of that period of time turn on an output. 4). The output does the required action and then resets. It might even show something on a screen that says it has happened ok and you can now stop pressing the button. Hmmmm. Well that would either be a timer, or a count incrementing in value, continuing to do so whilst the button is held on, and then resetting ready to do it all again on next long push. It's over to you now to work on this idea. cheers, Aus

I"m sure it all comes down to tooling costs. But it has always been an issue, so if it was me I would have been fixing it properly. Everything I use them with is 230s so is the even older problem and only gaffer is possible. And yes, roadies still use reams of gaffer setting up concerts/stages! cheers, Aus

That's great, but I can't help today, too busy. Others will. If not....I'll Be Back!!! Just for your own knowledge, I would play with SD card Explorer and see for yourself how slow the SD card interaction is. Anything that uses the SD sometimes doesn't work as you would expect. Same thing with anything that uses buffers.....might always need a few more scans after saying it is ok. cheers, Aus

OK. Didn't think it would solve the issue. Did you try changing the write to a manual trigger like Gabriel suggested? Change things so that the write only occurs on some input you do manually. Then do this a few times with a space of 10 seconds, say. Then see if the write is ok. If you can't get to the bottom of this, perhaps consider changing what you are doing. Store data into a table, then periodically copy the entire table into a udt file on the SD, and then manually retrieve that from the plc on a scheduled basis. But I'd persevere with this first, it will likely be something simple. I seem to recall a line count somewhere, is that correctly rolling over? cheers, Aus