Ausman

I think the final solution is to again go to your supplier with the issue and: 1) If they already have another unit on hand get them to check straight out of the box whether the problem exists on a virgin unit. If it doesn't go to point 3. If it does go to 2. 2). Get them to source a "fresh" unit...ie not from the same "faulty" batch and when it arrives get them to check again. Once the problem is definitely not happening on a new unit that has never been touched by your program or anyone else's..... 3). At your supplier's premises, check again for yourself the issue doesn't exist on the virgin unit, preferably using the computer you have been using all the time. Then in front of them load your program and see what happens. If it is ok on just a load, next do a burn, then an upload data as well...checking each time. In theory your program can't be affecting anything, but by ensuring that a virgin unit is ok and then immediately checking whether your program upsets something on that same unit will be a good pointer for Unitronics to follow up on. This is the only way I can see of resolving this once and for all, yet still keeping your program "private". If your program does upset things somehow, then Unitronics needs to know about what you've (inadvertently) done that causes it, because it (perhaps) shouldn't be allowed to happen and whatever the error is needs to be corrected. cheers, Aus

If it does it again after all the suggestions, please post 2 screenshots of the output window showing SI5 to SI42......before and after.

Correct. I always use Set RTC....I never do it by manual editing internally, except through info mode if necessary.

And check that the battery is actually OK again.

OK. First a clarification that seems to be causing confusion. In asking you to do an Initialize & Reset, this seems to have been interpreted as directly using SB24. I was actually referring to the available action in Visilogic which is Connection/Communication & OS/2nd tab bottom right. But however it is done, it shouldn't make a difference. Did you do the I & R just like I said after each separate download? I know that this is an insulting question, but have you got the battery in correctly? And do any MIs that are in use retain their values after power cycle? Try removing the battery for an hour or more and see what happens after reinsertion and an I & R upon reboot...using the Visilogic button. cheers, Aus

Hi Rel, your english is better than my french! Please clarify.....is there a "no application" message like in the above screenshots, or is the application there but it has lost the previous parameters? These are 2 different problems. cheers, Aus

Not that I know of, but this is such a variable that it would be hard to enforce, given the innate address changes that might occur across the network anyway, depending on the setup. Happy for someone else to say I'm wrong. I do recall Joe T having a method of using MAC address to verify access, but I don't know whether it can be used or is suitable for your application.....I think it was for some other sort of direct access. I'm sure he will elaborate on this soon, given my mention of it. cheers, Aus

Uhmmm...so where are you up to at present, Mal? cheers, Aus

Doing an I&R, or using SB24 should never clear the RTC data, though. But I do like the thoughts of Isak and Kratmel re the network card. cheers, Aus

Hi Mal, before doing anything else, have you tried an Initialise and Reset? Try it first with your program in place. If it doesn't help, try burning an empty program, do an I&R on that, then do it all again after burning your program back in. Using I&R has cured occasional very odd behaviour on a system for me. Bits on that shouldn't be, strange MIs. It seems to mostly be on programs that have had lots of changes implemented over time, and I'm guessing that the "program variation process" doesn't fully clean things up on the plc as one would expect. If it doesn't help, go for Flex's offer! cheers, Aus

"I know nothing of the hardware activation" https://unitronicsplc.com/activation-faq/ Quote from that page: "In cases where you download the application via USB (memory stick), you can voluntarily carry out Hardware Activation via alternative methods" doesn't seem voluntary at all.....more compulsory. Answers please, Creators. cheers, Aus

You raise good points Walliemg. I don't use Unistream but to me it does seem to be the wrong way to be heading. cheers, Aus

Hi Cheris, this might sound harsh, but the forum does not do your work for you. I once said this in another post: << The real art to programming plcs is to first break down your process to every single procedure you are going to need to achieve your desired result, and then arranging those procedures to achieve this result in the most efficient manner. (You need to remember that in general plcs are very dumb and need to be told how to do everything.) I do this using a spreadsheet owing to the ease of moving things around, but there are many other methods including whiteboards, depending on complexity. (Some people end up with a correctly drawn flow chart once everything is finalised, but for me that isn't needed.) Once you have done that, if there is a procedure needed that you are unfamiliar with, or haven't used before, you then go to your plc's list of things it can do and find the function/maths/compare etc that best matches what you need to achieve. You then learn everything you can about the way it works, by consulting the help files, looking at examples and then physically doing a trial, using the plc, of something simple involving that procedure to ensure you are totally familiar with the way it works. Eventually you can tie it all together into a fully functioning, simple as possible program that the little men, women and gender neutral people (we are very PC on this forum!) running around inside the plc are quite happy to do over and over and over again without getting tired. >> Members of the forum are very glad to help when you have a question regarding an issue/question/problem you discover when developing your own program using the above principles. We all started from basics, using help files and experiments. cheers, Aus

Yes I did, I posted the google English translation, which says exactly that. cheers, Aus

Try removing the MB0 inverted contact from rung 3. And I thought that those times relate to the update rate. Sorry for not helping much.....I haven't done this for ages, and even then it was just an experiment. cheers, Aus

Have you fully read and acted on the manual I have attached? And also originally installed the program using right click run as Admin? cheers, Aus UniOPC_Server.pdf

My initial look has me worrying about the message at the bottom of a number of the screenshots. Incompatible hardware config........It appears that you have a different model in use in your program to the actual plc. Try rectifying this first and see what happens. cheers, Aus

Agree with Joe and Dan. And on Dan's comment in particular, my take is is that it is all related to the evolving fascination with "everything you need to know" being readily available at the great source of truth...the internet. That has generated a myriad of useless jobs/positions that demand the ability to justify their existence, but in reality are simply "tick the box" positions that don't really achieve anything except a fat bonus for great work done by actually tallying info produced by others' hard work. When originally if Widget X was being made ok, the machines weren't indicating any error, and the production was logged and regularly reviewed, it was fine. Nowadays we need to know RIGHT NOW if production is OK. The process and physical results are just the same, but there has been a raft of other ridiculous issues brought into the equation by the ever increasing expectations of data availability. The implementation of I(I)OT is where I see a nightmare approaching, yet the proponents think nothing of some of the instances that exist, eg the simple act of turning on a light needing an internet transaction b/n a remote (whose?)server and the light fitting in question. dumb dumb dumb End of rant! cheers, Aus

Translation via Goooogggle: Experienced programmer, teacher Visilogic, Unilogic. I will write a program for your requirements write, order work.

A single analog input can be used successfully to implement multiple switch inputs if you need to go that far. Depending on different switch positions, a different resistance is applied resulting in different analogue readings. You have to map this out carefully if doing this approach, so that every switch combination gives you a distinct "zone" of an input, and you then use a range reading in the plc logic. If you use a single value you will likely run into problems. In setting this sort of thing up, I always use a multi-turn 10K trimpot (or a number of them) to initially find optimum resistances for what I want. Theory doesn't necessarily work out correctly due to drift, component tolerances etc. cheers, Aus

I think that there are a number of ways you could solve this. One solution I can think of is to write the logging as excel in the first place. This wouldn't take too much programming to change from the current method. Another would be to keep the existing UDT file generation in place, but modify it to use the append function to also make a very large udt that has all your data in one hit. This would then only be one conversion. I haven't ever done this so don't know about size limits, and quickly looking couldn't find any info. Someone else here may know. I strongly suggest that you look at the help file in Visilogic, use Index to find SD, and then explore everything found. You will likely be surprised at what is available that can help your situation. The original programmer has gone down a certain path, but there are many others available. They will all need work done at the plc end, though. cheers, Aus

OK to all of that. More thoughts, not in order of importance...just as the brain spat them out. Did you actually check the socket pins? There are many ports on these things and it is easy to put a wrong plug into the sockets if care isn't taken. I have seen this result in bent socket pins that then don't align correctly to the plug. When it breaks, I think you should go into info mode and see what the plc is saying about the port. I'd also run a sniffer on the network and see what comes back. Also try another address in your program and change the router etc appropriately. Perhaps there is a collision happening that you aren't aware of as it isn't on all the time, and these tests might show it up. Have you done a full reset and init? Download an empty program and burn it. Then go to Connection/Communicaton & OS/2nd tab Bottom Right button and work it. Then Download and Burn your program and do a reset and init again, then see how it all goes. Ask your supplier for a "loan" card to either fix the issue or eliminate the card as the culprit. Either way it shouldn't cost you anything. cheers, Aus

This post appears to be doubled into here: Elijah, please do all further posts in that one. cheers, Aus.

Ravi, don't forget you need to be logged in to get any file attached to a post. cheers, Aus

Many things have been covered here. You need to go to the basics and start again with just the network ladderwork, which you do seem to be pursuing. That said, has the 130 been connected to other things? It is possible that the socket's pins have been damaged. Check carefully that all pins are properly in line and same height. Also try another cable. And also reseat the adapter, ensuring it is done carefully and properly. If all that still fails, get another card to try.....even if you are an electronics whiz don't go trying to fix the unit.....Unitronics would much rather have it back for research if it is indeed faulty. cheers, Aus