Ausman

Also, have you got SB168 on?

Sorry, been busy. Yes, again, install/run as Admin. The only thing that wouldn't work for me in those settings is that the timeout is too short. I can't see how this would give you that error though. I've never seen it. Aus

Hi all, Again on 9.7.55 Build 0. Nothing major but it was confusing. Tidying something up and was able to get rid of some timers. In deleting them, the "Use" tick wouldn't disappear in the Operands display, even though the program could find no reference to them in a search. Compile didn't help either. I finally found that if the type was TA or TE, you have to set it back to the "default" TD, and then the tick disappears. Cheers, Aus

Hi all, some of you might have read my post here: http://forum.unitronics.com/topic/3992-unit-id-check-etc-on-online-test-first-login-on-a-bus-system/ I have been trying different approaches to this problem and have finally found one that makes it a bit easier. I have always had multiple instances of Visi set up for when I am writing code. If you don't know about this capability, read this entire post: http://forum.unitronics.com/topic/3884-question-about-visilogic-coding-operation/ to get the overall picture and pay attention to Shane's post at #4. For my multiple online monitoring I have had great success using many multiple instances of Visi, all with their own access address and program set for the plc I want to connect to on the same system. I leave all the instances open, overlapping enough to be a useful size but able to be clicked easily to bring that window into focus. I also run a remote access instance set to another sub-address on the unit that I just only need to observe. I have found this entire process to be invaluable when needing to skip quickly between various plcs on a connection. Instead of disconnecting, finding and loading the relevant program again, changing the unit id drop-down and then finally clicking connect, you simply disconnect in the currrent window, focus the relevant one, click connect and you're in. AND on the correct plc/program match without any stuffing around.....as long as you've got it right to start with! I have found this to be an absolute boon on working on a system that was previously a PITA to monitor and adjust due to all the linked plcs. The only caution is not to forget to disconnect on switchover, otherwise the network error comes up. But truly, it's a doddle compared to the previous way! Cheers, Aus

Hi again Marko, I can't open your images so can't comment too much. To perhaps help you with Linearisations, have a look at another post of mine that has a calculator. It makes it easy to see what results you should be getting from inputs, and also better explains X&Y. http://forum.unitronics.com/topic/3540-linearization-calculator-for-all/ cheers, Aus

Hi Marko, your English is much better than my Croatian!! Additional to Flex's comments, before doing anything further in the main program to show the values, check the following points and then make sure that the raw input is showing a value and moving up or down appropriately. 1). Look at this forum topic: http://forum.unitronics.com/topic/3920-thermocouple-no-reading/ You may not have power to the snap-in module correctly set up. It is very easily missed and you will not get anything analogue until correct. 2). Make sure all the jumpers on the module are set correctly. Carefully read the information sheet about the snap-in which explains it (and the power connections if still puzzled) If you don't have the snap-in set correctly and power supplied to the correct places you will not get the result you want. http://www.unitronics.com/Downloads/Support/Technical%20Library/Vision%20Hardware/Snap-in%20IO%20Modules%20-%20Specifications/V200-18-E5B.pdf cheers, Aus

I have never encountered this error. Flex is correct. If you are connecting ok with some things, you should be OK with others. Have you got everything installed and running as Admin? Anything and everything from Unitronics I always install, and have shortcuts set as, run as Administrator. cheers, Aus

I know what you're saying Flex, it also annoys me. My workaround is twofold...I make sure the Save As window has the "date modified" column always clicked correctly to show the most recent file at the top.....do it once and it should stick. 2nd method is if the names are complex, I do a quick excel sheet with progressive sequencing to save me the trouble of typing it correctly. I leave the sheet open and just copy and paste the next version name. As an aside to this complaint, has anyone found a good replacement for the fantastic DataKeeper program of old? It was put out with PartitionMagic years ago, well before most users even knew about partitions, and was the best backup program I have ever worked with. Simple, effective, easy to use but sadly won't run without hiccouphs under anything younger than XP. It's beauty was twofold. It would backup any new save within any folders you set, immediately. The real winner was that you could specify the number of copies it keeps of the same name, working on a FIFO basis. So you could just keep on using the same name and you would always have your prior versions there in case you needed to go backwards. You can immediately realise the benefits! I used to "pingpong" b/n a digit change on the names to make it easy to start with in case of a minor "rewind" needed, but the "how many copies do you want to keep before I get rid of them", was fantastic. As well, if you ever needed a full restore it simply lifted the latest version into the restore. Perhaps someone has some clues as to how to make it stable under Win 7 etc? I tried all sorts of compatibility settings without luck. Boohoo. cheers, Aus

Raising this one again with an observation that might help. I went to this site recently for checks and fixed the card issue whilst there. It was curious in that Windows could see the file in the correct window, but when I asked to delete it, I was told that the file didn't exist. Out of interest I ran a few workarounds including rename (couldn't work), disk checking (which told me it had fixed errors) etc but the problem remained...the file was visible but for the system to delete it was impossible because it wasn't there! I didn't bother trying in dos etc. Time was short so I simply lifted the relevant saves needed from the card, reformatted, and then wrote back before insertion. Obviously there was something fundamentally wrong with the file system on the card....I don't know enough about the way they work....but someone might consider this helpful. Maybe the delete procedure has a glitch where it can end it's process a little bit earlier than it should in certain circumstances? Anything involving SD card actions when inserted in the plc takes a verrrrryyyyyyyyy lonnnnngggggggg time, perhaps it is tied up in this? Cheers, Aus

Hi all, I'm running 9.7.55 Build 0. I would love the remote log in/online test process to include an initial check that you are actually talking to the plc in the program you have opened on screen. It is very easy to lose track of things and select the wrong address from the drop down box. I have had instances of worry as I then read really weird things for that PLC because I am actually not logged into what I am looking at on screen. The program happily reads and displays all the operands, but they are the wrong ones! I don't think that it would be too hard to have an initial check on first access that is then remembered for that session. A variation of the "Get OPLC Information" action. Is there also a way to change the names of the dropdown Canbus/485 IDs? Having a specific name would also help on this issue, rather than just the ID numbers. Finally, given what I'm first asking, could the check also include a look at the program names, to check if they match? Again, during mods, I have sometimes been caught out through switching b/n various versions I am developing, with what I am watching not what the plc has. I know that this is all basically a human error type of thing, but it would make life easier and isn't that what it is about? Cheers, Aus

Hi Sweis, I haven't used graphs, but I can see a few things in your pics. 0). Are you sure there are no "overlaps" on the screen that might be affecting adjacent areas? 1). There appears to be no relationship in both pics to your ppm. The top one shows things at mostly 1248, yet the graphs look like they are trying to be in the red. The lower pic you have much higher ppm and it looks like this is your high target point, yet everything is in the red. What are you trying to display? 1248 as red or 9999? Should all the 1248s just be yellow? Or is the displayed ppm number a varied setpoint input into the Linz function depending on whether the gassing is on or off? 2). Why have you got a minus sign in front of ppm in the read? Just a simple description error? Or perhaps it might be related to the issue. This raises the question that someone else can answer as I don't know: Does this graph function only work correctly on + numbers? 3). Although others on the forum have said they have never had issues, I have sometimes encountered problems doing copy and paste, and then just changing relevant numbers. The system has seemed to keep some internal reference to pasted code, even though everything obvious has been changed, and things have gone severely haywire. Although it will likely be a bit tedious, perhaps try writing that screen code as separate starting points, without any pasting, and see how it goes. 4). I'd also do your code write as a progressive thing. Do each graph completely but one at a time, save accordingly, test things at that point, then if ok do the next one. Perhaps this might show up something. 5). Have you monitored all the raw 4-20 inputs during running? Are they correct? ps did you like my PLC numbering system for the points? ho ho. cheers, Aus

Hi Vasil, There might be other ways, but the only "easy" way I know of is if you have a small computer linked to the PLC via serial or ethernet, permanently running the Remote Operator program, which is a free download on the main site. You are able to set the image of the HMI to full screen in Remote Op. I have done such a link whilst running prolonged testing on something. I use small computers from a firm called Eway in Taiwan....google "eway taiwan". You can get a fanless, no moving parts system this way if you also use an SSD, and they also can have serial ports if needed. I am not affiliated with them, but I use their products and they have served me well. One other thing...I haven't done this, but I expect that if you were running a touch screen monitor you could control the PLC as well. If you just want to only observe it, leave mice etc hidden from fiddling fingers, as Remote Op is a controlling interface. cheers, Aus

Hi again Lawry, just to clear what might be confusion, the encoder I quickly found matching numbers for was a draw wire one, that was why I commented on the 50m of line as being unusual and perhaps the encoder being better located on the ground. And also the laser comments etc. But I must have found a wrong reference as with further digging it looks like you're deriving a count from a mechanical rotation means on the lift. That might clear up some of your head scratching on my comments! I'd still be logging things as a first step along the solve path. Cheers, Aus

Hi Lawry, 1). You have the resistors, but is the software termination set correctly at the encoder? 2). So either Can on it's own generates no counts on their error bit at all? But if you run both Cans, does the error rate rise dramatically on each or one? Maybe indicating some sort of buffer problem which might be simply fixed by timings changes? Again, I'd also be trying to log where the lift is at the time of failure. 3). I personally would be putting the encoder as fixed, not on the lift, to make things a bit easier. It must have a hell of a rewind spring to hold up 50m of joining line! Or have I got that wrong? To me that's fundamentally wrong locations for the various operations, but I don't know the install's quirks. It sounds like the 130 is telling the system the location of the lift, but this indication is then via the flexible link. I'd have the 130 purely as a "remote control" giving instructions to the 1040 and nothing more. The 1040 does all the work which would likely let you get around issues a lot easier. And I have a little bit of a problem with the encoder being bus based anyway. If the potential is there to drop packets that indicate where something that moves is, I see this as a problem. It might be impractical for your situation, but I have used laser distance encoders with success in some of my stuff where lineal counts weren't accurate enough. Not good for a dirty place, though. My final positioning is done by other shorter range sensors. The distance stuff is for "transition b/n endpoints control" speed control. Although in theory counters never lose track of where they are, in the real world I see it enough to implement other controls to double check this or handle things appropriately. Cheers, Aus

Me again, perhaps also link your bus error bit to a distance logger, being another check to see if it is a failure due to a particular distance. At present it might be mostly riding through a dud zone on a few retries and very occasionally getting caught out, but if you log every comms failure, it might help isolate it. cheers, Aus.

Sorry, just read your first post about this, cable looks like it has been covered. Check it anyway just in case! cheers, Aus

Hi Dan, have a good read of this post: http://forum.unitronics.com/topic/3454-usb-rs232-adapator-erro/ It has a lot of helpful pointers, the main one being it is worth spending $ on a genuine prolific based adapter to save headaches. I am also bothered a little by your "serial to RJ11 cable which I have been using to connect another PLC to my computer" statement. I would have a good look at google image results following a query for MJ10-22-CS25 and check that the existing pinouts are correct. cheers, Aus

Hi Lawry, +1 to all that cliff suggests. I have some more possible pointers, some of which might not work but come to mind as something to investigate without knowing the full system. And apologies for suggesting stuff that you might already have in place. 1). Chased your encoder and it looks like it has many parameters that are programmable, one of which seems to be termination. So as with cliff's termination resistor pointers, check it is correct. Probably easy to miss. 2). How is the flexible connection b/n the 130 and 1040 achieved? Is it through a line "dangle" or a commutator system. Either way, perhaps there is an intermittent connection issue there, which could be a devil to find. If all else fails, perhaps duplicating this link might help. If it is a rotary draw commutator system check it over very carefully, consider changing to a mercury based one if possible. 3). Consider changing the Encoder to something else that lets you use the high speed inputs on the 1040, instead of a bus system encoder which might be confusing things at present. By the sound of it you are running both unican and canopen, I have never done this and perhaps it is hanging together most of the time but then cracks the poops for some silly reason. Different input encoder might cure this as it is then only running one bus. Might also have a side benefit of making your positioning better as it will have quicker reads. 4). I'm assuming that there is a limit switch system in place for initial location setting by the mechanism on cold booting. So as an auto reset, you could fit another input from the drive system that registers movement, like a simple inductive, that then sees if it roughly matches what is supposedly happening, via programming. ie my drive is meant to be working...the inductive shows there is something going on but the encoder says zip = error. If it throws an error it initiates a full reset and the system will fix itself at the time. Not ideal, but would keep things going. I have this double check sort of system on all my projects where this sort of operation happens. You can also log the parameters at the time and this might point you in a good direction, as something might appear. eg it consistently drops out at around 24 metres. 5). Do the same reset thing with the 1040 and 130, with each of them having an internal counter reset by the other to check if the comms are still in place correctly. If they fail the test then like in 4) it triggers a total system wide power reset run by an external timer for 10 seconds, say, initially triggered from the plc. (edited this last for clarity) 6). Good luck. Intermittent faults are a right PITA but you can do some things to make the job of finding them easier. cheers, Aus

+1 to what Joe has said, although I'm not so brilliant!! (Is there an emoticon for "grovel before master"?!!) I well remember scratching my head years ago on the very same issue, . At the time, I thought it was just me being stupid, but given that it looks like other people seem to be caught on this one, perhaps the literature should make it a bit more obvious. cheers, Aus

Hi all, A small suggestion, and comments please. Wondering if our beloved makers can change the Unican addressing system in the FB slightly. I would love the destination address and vector Descriptions to be listed just as text, rather than refer to the details in the sending controller. It would make things much less confusing, as you could then name the MI and vector as you have them in the destination system. At present this isn't the way it works and it can be irritating at times when the brain gets things confused! cheers, Aus

HI MWD, I agree with your comments about this cut/paste problem. Not the solution you are looking for, but the workaround I do is to use export/import subroutine, in Project, with the 2nd instance open. The two instances happily refer to the same location you use for the export/import. For me it is always a tossup as to how much effort is involved in editing the sub pasted in, as against writing it from scratch or altering existing. An alternative thing I do in this situation is to do a print of the other program as a pdf, and keep that open to refer to when writing the changes into the new file. If the change to the program can be made by the "team" it would be great. cheers, Aus

Hi John, you need to look a little further down the forum column! I've given up on it for now, but others seem to be doing fine. http://forum.unitronics.com/index.php?/topic/3587-visilogic-and-windows-10/ cheers, Aus

Thanks EduMarg, that is great. I also feel compelled to mention that another brand I work with has a linearisation function where you can specify multiple X Y relationships throughout the input range. It maps out points derived from what would be a sequential set of MIs in Unitronics language. These give the matching X & Ys for however many points you want to specify, to give you a varying relationship to the rising input. So it is still straight line based and not really a "curve", but for my needs it is very handy and vastly easier than the existing Unitronics method. ie one ladder entry as against a vast number of them! The ladder entry would look something like [LINZEXTENDED -- Input -- Curve Specs start location -- Specs length -- Output] cheers, Aus

And to perhaps make it clearer again, Write a new program that simply has a Linearisation. Make X1 1000, Y1 1000, X2 2000, Y2 4000. Run the program on the plc and manually vary your input. You will find that if you give it an input smaller than X1, or greater than X2, the output will run outside the Y1 & Y2 values. eg. Input 1500 and out comes 2500, which is within range. Input 500 and you get -500, whilst input 3000 and you get 7000. The output doesn't stop at the Y1 & Y2 values. That is what I am wanting. The ability to set a max and min value as part of the function. And perhaps also have a look at my post: /topic/3540-linearization-calculator-for-all/. My calc imitates the actual plc ops. cheers, Aus

Hi again, and thanks EduMarg, I am well used to using Linearisation. My PLCs are usually V130s on this sort of thing, but the problem is generic. The easiest way of explaining better is a theoretical example using temperature: From 22C to 24C I need to linearise an output to a variable speed motor over a partial amount of its span, say from 6 to 8ma. Between 24-28C the output stays at 8ma. From 28-36C the output again gets linearised from 8-13.5ma. 36-52C it stays at 13.5ma. 52-120C it gets linearised from 13.5ma to 20ma. For this to happen I have to do multiple compares and stores related to each linearisation to make the output stay at the desired ma once the input goes through the range that needs the particular lin. A different example is that even if you only have one lin, but don't want the output to vary when your input goes above or below certain levels, you still need 2 compares and stores as the output just proceeds along the path dictated by the lin parameters. I hope this explains it better. The linearisation function does not have max/min output settings, the output will continue to increase/decrease in the straight line derived from the lin settings. Cheers, Aus