Simon

Good to hear it is solved.

I agree this is a reasonable expectation from the market, and I was asked about this in the last training session I ran.

A multimeter doesn't give you a very good picture of the encoder signal. An oscilloscope would be ideal, even just a low-cost handheld one. If your multimeter has a frequency setting, that can also give you more information than just mA or Volts. Do you know the output specifications of the encoder? It can be 5V TTL, Open Collector (either NPN or PNP), push-pull, line driver. If you look at the direct, digital values of I0 and I1 do they change at all whilst turning the encoder very slowly?

At least you now know how it is arranged. I think you will need the help of the IT people if you want to set it up so that all PLCs were visible as a single network. Possibly a VPN would be the way to go, but that's just a suggestion.

I have seen this happen with a water pump system. Distances were not much different to yours, but a nearby lightning strike would take it down every time, and the PLC would lose one or both on-board ports as well. That problem was solved with V200-19-RS4-X isolated serial cards. Hope this helps.

Firstly, from the diagrams I downloaded, A2 is the negative, A1 and A3 are positive. I would double-check that first. Otherwise, the principle is correct, you would need a diode from each of the positive control terminals to the negative terminal. It seems odd that these don't have it built-in flywheel diodes, but the datasheet does not mention it at all. Also make sure you have "break before make" with your relays. If you turn one output off and the other on in the same PLC scan, there is the chance that both relays will be on for a fraction of a second. I have seen this happen. My solution was to insert a small delay between turning off one relay and turning on the other relay (say 100ms).

It sounds like you need a flywheel diode on the contactor coil. This is a diode across the coil terminals, that is reverse-biased when the coil is powered, but allows current to flow when the PLC output relay turns off. Basic power diodes like IN4004 would usually be adequate for this.

Here's one we prepared earlier, with example programs: the logic to decode the Gray code is not that hard once you look into it.

I have been asked a question about which operands are used by the Advanced Webserver. I always thought this was clear, but when I go searching for the answer, I can't find one. The question was posed in the old forum (go to final post) but was not answered: http://www.unitronic...858&whichpage=2 Specifically: The person who asked me the question also reports that values are being overwritten even though they are not listed as used in the basic webserver program. It looks like the advanced webserver uses some vectors, does any one have a comprehensive list?

I can offer at least a partial solution, that will allow you to compile and run the application. In each keypad entry variable, un-check and then re-check the Keypad entry checkbox. This will clear the limits back to zero on both upper and lower limit values. Keypad entry will work, but you will need to apply validation in the ladder. As to why this issue has arisen, that is a question for the creators.

I tend to use the online mode in Visilogic and view the I and O status at the bottom of the screen. To make it easier you can also add the specific I/O you need to a watch, so they all are together in the same place. Information mode is also a good option. The default information mode password is in the help file, search on "information mode".

Firstly, to answer your immediate question, the HOUR function and SI31 use a different format. SI31 is simple decimal representation, whilst the HOUR function uses a BCD format. See the help file for details. Changing the display format on your HOUR MIs to HEX should make it look right, but that still won't allow you to use a direct compare function, which leads to the second point: You don't need to perform a manual comparison when the indirect clock functions will do this for you (search "indirect clock" in the help). If you still have a reason to use the manual comparison, I think the BCD to NUM function would work to convert the indirect clock format to system time, or the NUM to BCD would convert the system time to indirect clock format (but I haven't tested this)

I do tend to agree, especially when there are large images to download. Also, I notice that there is a time limit. If you don't acknowledge the message within a certain timeframe the download will crash out and you need to start again. It would be nice to have the option to inhibit these prompts on a project-by-project basis. Note also that the UniDownloader can be used to download without user interaction, but that in itself requires several steps to create the downloader file. It can be an advantage in some situations, but is not a convenient cure-all.

Can you post your Visilogic application (vlp file)? Maybe there is something in the logic that means one block works OK and the other doesn't. Do your "poruchy" block and "hlaseni" blocks have any phone numbers in common? Can you try the numbers that fail in the "poruchy" block and see if they work in the "hlaseni" block?

Looking at your images, the black outlines are the most obvious problem. You could reduce the contrast, by using a grey rather than black. Or change the style of the image so the black lines are not used at all. Also try to avoid features that are only 1 pixel wide, make them 2-3 pixels wide if possible.

Reading the frequency of relatively slow pulses is always a grumpy sort of problem. Firstly, I think your approach is as good as any. The HSC frequency measurement has a maximum timebase of 1 second, and will give a lot of zero readings on this type of signal. With a measurement resolution of 1.25ms on a minimum pulse length of 100ms, you should not see a huge variation due to the timebase (approximately 1.25%). I do think one of the problems with this is the human expectation of what the data should look like. With a slow signal like this, you can see the natural variation in the signal. If you filter the signal, it seems even slower. In contrast, a fast signal can be filtered, and still look fast to the human observer. However if you want a smooth signal, you will almost certainly need to filter it. Maybe use a filter of 5-10 values, by calculating the values as you currently are and averaging them together (use the FB filter block). At higher rates of kWh usage the values will come more quickly, and your filter will give a faster response.

The V570 has a 320x240 screen resolution and that is fixed by the manufacturing process of the screen. Even if you *could* force the V1040 OS into the V570, it would have no effect on the screen. To get the best results, make sure you design your images allowing for the full 65k colour palette. By doing this you you can improve the appearance to some extent with shading. When you create shapes in your PC graphics program, make sure the Anti-alias property is turned on. This automatically softens the edges for you. However at the end of the day, the 320x240 resolution will give you visible pixelation.

It usually means that the number is not valid. It is not related to the ladder logic, although just check that you are waiting for the message to be completely sent before performing any other modem-related actions. Did you use the full international format for the number? That is: + <country code> <phone number> Check that you have typed the numbers correctly, and that you can send an SMS to that number from your mobile phone. Also, what modem are you using?

I haven't tried this, but as I understand, if it's a full Windows 7 tablet PC, it should be OK. You can even run Bluetooth to serial dongles for programming, so I am told. If it runs the dedicated Windows Mobile OS, or whatever it is called now, then probably not. I haven't tried this myself, but would be interested to know what you find.

Open your SMS configuration, look at the top right corner, it is set for COM2. Change this to COM1. If that was the only problem, then you should be up and running.

The value of 6 in the send fail bitmap means index 1 and 2 have failed to send (value 2 + 4 = 6) Each bit of the send fail bitmap represents one phone index.

Firstly this is an unusual situation, and I would only expect limited success when trying to do this. Since they are on RS485, both devices will see each other's data, and it is a matter of "chance" as to whether the devices can tolerate seeing data that they do not recognise (of course it is not really "chance", but comes down to how the devices are designed, but you don't usually get this information up-front). One possibility is that the ASCII device does not know what to do when it sees the Modbus data. The Modbus device on the other hand, should just ignore the ASCII data, since it would not be a legal Modbus packet. It seems like the ASCII device gets confused by the Modbus data, then is not ready for the ASCII data. The first ASCII request after Modbus helps clear the situation and then the device is ready for the second ASCII request. Depending on the settings of the ASCII device, you may be able to change its settings to more quickly discard data it doesn't recognise, for example with timeouts, character delays, etc (make them shorter). Maybe the ASCII device is waiting for a specific terminating character? Otherwise I would suggest separate serial ports. If you only have one port, there are serial switches available that require a control code to switch their output. Since you are already using the FB Protocol blocks, that device is also a reasonable option, assuming you can use RS232 on both devices (http://www.bb-elec.com/product_family.asp?FamilyId=102).

Ditto Ditto on the above, Another issue to be sure about is the structure of the IP network - as the addresses you have indicated are "Class B" addresses (he first two section of the IP address are the same, the last two sections of the IP address are different). Most of the Unitronics Modbus examples deal with "Class C" addresses (first 3 parts of the IP address don't change, only the last part does). Did the system admin also give you a subnet mask and a default gateway? Did you set up the networking on the PC that Remote Access is installed in, or did the IT people do that? If you feel like you are going in circles, I would grab two PLCs and set up a point to point conneciton with a crossover cable and the basic master and slave example programs. This allows you to test the Modbus TCP comms without having to deal with wider LAN related issues.

Just in case anyone was wondering, DataXport reads the template file in xlsx format by default. I haven't tried testing if the checkbox "Force Excel 2003 Extension" tells it to read in xls format, but I suspect that to be the case. It took me some time to find that at some point my dataxport installation folder had been renamed from \\Dataxport\ to \\Unitronics DataXport\, so I was putting the template in the wrong place. I think it might have been the windows migration wizard did this when taking the settings off my old Windows XP PC and loading them into the new Windows 7 PC.

IMTS - International Manufacturing Technology Show http://www.imts.com/ (I needed to Google it, there's one exhibitor from Australia...)