Ausman

Hi Vamal, welcome to the real world where specifications differ from actual operating conditions. Even the temperature of the medium alters running times on these things...and load conditions always mean there are varying degrees of flow resistance throughout the circuit. We've discussed this a bit and you could try the alternative method of timed pulses. But it also sounds like you have been completely relying on the virtual position. You need to periodically force the valve to a physical endpoint and then resume your normal process. And you could build things into your program that check for unusual numbers and self-correct if necessary. A possible alternative is to implement the 2 DIs and have them not set for endpoints, but measure them between a much smaller span more often. This wouldn't necessarily affect the output much if you set them close to the normal operational span, it would only take a minute or so to do. Then adjust your MAX according to whatever the maths works out to be. The bonus of this method is that you might get one of the DI tripping during your normal operation, which gives you a confirmation of where the valve is physically. and an edit: don't forget that the switches trip at different points depending on which way the valve is running. cheers, Aus

Thanks Cara, I understand the reasoning. To get around the "outdated" issue, I would think it would be easy for your super programmers to come up with a little script that could accompany said Library, or even incorporate a "check for updates" button that could be included in the startup folders. Those who download it could then routinely run the check, and it could check all the documents in the local file and just update the ones that have changed. I use the library as my "ready reference" system and it is a great thing. cheers, Aus

Hi mkc, Without knowing Jazz too much, only M91s, 2 comments: 1). Why 2 stop bits instead of the standard 1? 2). Given that the problem plcs are the new ones, perhaps you should use Controller/Operating System to check that all the Jazz's are using the same OS. If the newer ones are a later OS, that might be the issue. If they are, the easiest solution might be to match their OS to the older ones, rather than changing ALL of the oldies to new. cheers, Aus

Everything Joe says, and I'd also be having them go over all their earth connections and clean them up/check resistance. The 2 years ok place reeks of something slowly drifting off ideal and your locations imply dirty environments. So all the other MIs stay ok? That is a strange thing. Do they do it when adjustments are being made or just whenever? Have you tried disconnect/reconnect all the ribbon connections in the plc system, too? Even internal ones etc? Is the front membrane still ok? cheers, Aus

Hi Cara, although a little off topic, this thread is a classic example of my whinge here: Immediate posters have done responses/answered, Visco has answered but because he is not immediate his replies haven't shown for them to consider. So other thoughts have evolved which then look odd when the system suddenly inserts Visco's responses into the thread according to their time of lodge, wherever that is in relation to responses posted immediately. Something really needs to be done about this. It is annoying. cheers, Aus

And now that I've absorbed the other responses from you just showing, I think you should first try the Filter function block like Joe's post says...more info makes the world of difference! If this isn't enough, then you'll have to set up filtering of the output from the filter...ie cascade the filtering. I've had to do this on some sensors I've worked with, ended up using timed vector copies from the filter function output that then got averaged. You can do endless maths, depending on how accurate you want to be. But given the medium is agitated, it's always not going to be perfect. However, if the material is fairly viscous, is the "wave" only an increase in height near the agitator's edge(s)? If so, you should do your level sense once the agitator is past the read point and the medium is stable, which would always be the "lowest" reading in the constant sensing. You would set up some rolling compares checking the "lowest" point in each "up and down". You'd have this compare happening every scan and then put the output into a filter function block and it would likely turn out very stable. ie Find the low point of the medium each time the blade goes past, and filter this. PS edit: The compare actions would be done on MI2 before you put it into the linearisation. You may not need any filtering at all given you're only doing 0-100 from such large inputs. cheers, Aus

Sorry Paul, my abbreviation of Linearisation! And I also see some or your other answers, just delivered due to the "lag in posting" factor for new posters. So the follow on question from your answers is: what type of sensor is it? cheers, Aus

And another few thoughts, I've assumed that you have the hardware configuration Mode settings at "Normal", not "Fast". This alters your input numbers range accordingly and might be upsetting things if incorrect. And for monitoring MI2 like I want, the easiest way is to open the Linz itself without being online. Double left click on the block, and once open you then click on the blue glasses icon at the top of the column and it will go online for just those numbers. Especially useful in your case as it will be fast. The main thing is what MI2 is doing. cheers, Aus

Hi Flex, I thought the same but without knowing the tank's layout details it doesn't really matter, the end result is the same. Visco is probably working around the way the output arrives and got to these number placements by trial and error. I remember the very first time I used Linz I scratched my head for a while. That's why I eventually made my excel with extra naming! It might be an ultrasonic that is at it's highest output when the target is closest. So if it is in the top of the tank looking down, the associations are logical, just his numbers placement into the "wrong" positions is odd. I'd do it your way. cheers, Aus

And also a PS to the above.....your descriptions MI 28-31 in your Linz look a bit confusing. MIs are useful as you can easily adjust them online for input tolerance discrepancy. But your labelling might be confusing you elsewhere? Also, just FYI, if tolerance isn't that important, you can use constants instead of MIs in this situation. Hmmmmm. I wonder if your inputs are going outside the ranges? Can you monitor and report back what numbers you see for MI2 during operation? There is no max/min control inbuilt into the Linz function. If your input goes under or over, the Linz will keep on going in its conversion, which can create issues. Please advise! cheers again, Aus

Hi Visco, bearing in mind everything Joe & Hots suggest, I am puzzled in the first place as to why you are getting the fluctuation you say with innate high filtering. Looking at your Linearisation parameters means you are only trying to display 1 or 2 digits most of the time. Have you found and used my Linz calculator here? It can help at times to visualise expected results. In your Startup Params post, you mentioned a tank field. Given that you also now say it is a bulk level tank, I can't see how it is changing so quickly that you can't get stable readings over a range which looks like you are doing it as a 0-100 percentage of full. That's a rapidly changing level in a bulk tank! What sort of sensor are you using? Perhaps it is positioned such that it is being affected by your incoming material? This would definitely account for your weird readings. Or perhaps you have MI22 in use somewhere else in the program and it is being written to more than once. Right click anywhere in the MI22 row in the Operands tab, and choose "find". Check out the results. There are many ways to implement filters which will do your job, but at present I am puzzled as to why you need it in the first place! It also just occurred to me that you should make sure your plc is physically set correctly for 4-20 input, if that is needed on whatever you are using. cheers, Aus

Hi guys, I might be mistaken but I think Michal is referring to what was available via "Unitronics_Library.zip". (I may have renamed this!) The last time I downloaded shows as January 2015 and it was around 160Mb. It sets up a folder called Documentation\Manuals & Specs within the main Unitronics program folder, and it has heaps of useful info....all in one hit. The current system only lets you download a particular file for each model or subject....very tedious. Please correct me if I'm wrong. cheers, Aus

Hi & welcome Antonio, well done to all on this one, and thanks Antonio for the good responses and also your obvious investigating/learning/efforts prior to posting. We understand reluctance to post code, but if it is not too secret, it might help. There is a wealth of knowledge here and we all started with our "first PLC ladder program"!! One other last method to check your entire program....find the person amongst your friends/neighbours who is a total computer klutz, ie even gets confused using a mouse etc. Get them to run though your displays and operations to confirm that it all works as you want it to and is easily understood. If there is ever a way for you to find a sequence issue, or make something easier to follow, this is it. The main reason for this suggestion is to ensure that everything is perfect before you ship it as your "global system". Much easier to fix it before it goes out! cheers, Aus

Yes, and also a fridge to keep it cool. Aus

I recently upgraded a client's computers with some nice little Lenovos. Perfect, except that they didn't come with any recovery media...you order what/if you want and they deliver as necessary. They say this is to save the planet's resources.....great idea. Here's the pic of what arrived. Have a good look at the ruler and something else in the pic and you'll understand my exasperation! cheers, Aus

Hi again Michal, without knowing UniLogic, I think you could possibly backtrack a bit. Find the max frequency the high speed inputs on the module can achieve, and then go backwards from there with the view to increasing the number of lobes on your shafting that your inductive senses. The aim would be to have the maximum counts per rev from the shaft that remains within the limits that the module can do, and then you can likely set things up via maths to achieve much closer control. Also allow a safety margin on over-revving keeping within the counter limits. You don't want your system being told to go faster when it is in fact already going too fast!! Only you will know this margin. cheers, Aus

I'd still be looking at changing the network to no parity. On the EBMs it is a case of using their dedicated program with higher permissions than are available to the general user. My understanding is that it sequentially applies "unlock" numbers to certain registers, that then let the parity be changed, then locks it again. This may well be available on the stuff you are using. As Joe says: cheers, Aus

Also wondering that there isn't another master on the network somewhere without realising it? Aus

+1 to Joe's comments on the No parity. I didn't mention this before but I did find your mentioning Even a bit strange. Nearly all the stuff I use comes with either 19200 or 9600 as default, but always 8,N,1. A lot of it you can't even change the parity from none. The exception is the fans I use from EBM, which arrive as Even. I have been told by them that "Ve are German und knowen besten und this ist the axcepted standarden und I should not changen things and commiten fingerpoken", but like Joe, I always change everything to 9600 8 N 1 and things are stable and work correctly. I can't definitely answer your questions about combinations, but I think you are faced with needing all of them in your coding. Happy to be told otherwise. cheers, Aus

Do you mean the entire 485 network works ok? If so, why are they then changing things to 9600 8 E 1? And if they have all commands not working ok once that is done, are they sure that everything in their entire network has that setting? Yes. Unless you have some means within the program to cycle to a new com init, the PLC will always be the last called during that powered up period, as Joe says. A button "preventing it running again" will not work as the program is only doing what you tell it....you want it to go to the settings you are specifying in your com init that runs on every startup. But as I am typing this I maybe understand your question better. Are you asking if you put an appropriate MB in front of your power up init that then changes state from an HMI instruction, will this stop it running and resetting the customer setting during power up? I don't think so. You'll just end up with no 485 as there is no init at all. Essentially what you are wanting is for the init settings to be matched to MIs, and I think you've got no chance of that happening. cheers, Aus

Yes to all of this, and you're not a curmudgeon, Joe. You are a person who has experienced all the things that life throws at you, and get rightly annoyed. Many of my much younger associates think that I'm old and grumpy. I counter that I have heaps more life experience that they will eventually catch up on, eventually realising the things they now see as normality are often really stupid. They'll eventually be annoyed at all the ridiculous things done by government, morons, losers, users, and all the other human failings/characters one encounters. One of my favourites is the client who whinges about annual maintenance fees of complex stuff. They don't understand my insistence that routine servicing is necessary and think my minor bills are high. It's essentially a big, complex machine running 24/7 and doesn't miss a beat because of my care. Yet these same complainers think absolutely nothing of the vastly larger annual service costs on their whizzy cars that maybe work 600 hours annually. When I bring this up it is "different". What garbage.....cars are just machines! There's nothing wrong with having a rant now and then! It lets steam out of the boiler. cheers, Aus

Hi again, I haven't tried the latest versions so if this fails someone else or the creators will need to step in. That said, I would definitely try redoing all your various installs as run as Admin and do the copy bit for virgin copies, as you have done. Remove all the unitronics programs and perhaps even try a manual check of the registry to get rid of anything somehow left over. A registry cleaner would likely help here. Then start again with the different installs you need to have on your system, running all of them as Admin. I would use the latest swapper. This will be tedious doing all the previous version installs over again etc, but I think it is worth a try. I always run anything I get from Unitronics as Admin, both the install files and the program. Also, in case it helps, what Windows are you using? If you are on 10, can you try it on 7 on another PC, or setup your PC as dual boot? 10 continues to mightily annoy me with my "10 test" laptop. It forever does huge downloads of updates eating into my limited bandwidth, changes methodology, breaks working stuff, changes settings back to what Msoft wants, and those same changes make the laptop unusable for a while.....just when you need it to work quickly. cheers, Aus

Yep, Honeywell's programmers have done it all for you on that one, including the fuzzying of the logic to learn your system's abilities. However, a V350 will certainly do what you want with some effort put into it. For now you could do the simple hourly verson quite easily and evolve the other versions over the months ahead. Good luck. Aus

Hi Jxay, I don't think this is as simple as it first looks. And Flex, don't you mean Indirect clock functions, given the need to be able to let the user adjust things on screen? My main work is HVAC and I use Unitronics for complex applications where off the shelf DDC stuff isn't flexible enough. I'm assuming that your program itself will do differentials around the setpoint according to presets. I also see issues where you might have large temp changes between time zones, which are probably best handled by the program ramping the temp between old and new, otherwise your systems may heat or cool unnecessarily, and uncomfortably. In this I'm assuming the temp control is for humans' benefit! As for the mechanics of the program, it all comes down to how much maths and programming you want to do. The simplest method is pretty much Joe's weekly hour count suggestion, having a screen or screens for each day, showing the setpoint for each hour period of that day. This is a bit cumbersome from the human's data entry viewpoint as they have to input/agree to each hour's temp setting, but it is simple program writing. It does restrict things down to changes on the hour, though. Method 2 is if you are willing to do a lot of maths and complexity in the program, you can again have the users in control of a daily screen. This daily input automatically calculates the time into the weekly hour count...but it is essentially user generated and down to the minute. The times they enter are actual times based around 24 hour naming. eg 230 for 02:30am and 1345 for 1:45pm. Your user then agrees to/enters the start and end time and setpoint into fields on the screen, and the program automatically reads the finish time and puts it into the start time for the next period and displays everything already done for that day. Having the program move the end time to the next start time is important, as it gets around the issue of overlaps. It ends up at 2359 for each day's end and then the input screens start again for the next day. You either do the time storage based on what day it is, or do the total weekly count style again. My initial thoughts are that this would still need to have a maximum number of setpoints per day otherwise things are going to get very complex, but perhaps once into actual writing the program this might not be as hard. You put the time zones and temps into a spaced series of MIs that are then displayed according to how many are in use. You are also going to have to work up a rolling compare program to change the setpoint in use according to the RTC time. Hope you get the idea. I've just rattled this off. I call this a terrific learning curve. You might call it an "ohh.....what have I got myself into?!" cheers, Aus

Keeping in mind Joe's last as important, I think that you only need to measure your speed at C with no other input at all. It appears that your are arranging the hydraulics to take full care of all the tensioning requirements, so you don't need to monitor the main rollers A & B. If C is spinning then everything else is working ok, and you do your vfd adjustment from there as it is the primary control source. Perhaps you could also do a read of B's revs to check that it is going ok, but owing to it's changing diameter the revs will differ across a large range relative to the vfd setting. You could use a distance sensor to measure the changing diameter and do maths to allow for this, but that is adding complexity I don't see as necessary. So the speed of C, and your method of read, is important. The more pulses per rev the better, up to the max the controller can correctly read. Aus