Simon

From the datasheet, the response time is 10ms on all inputs, except for input15 when it is confiugred as a High-Speed input. I had to read it a couple of times to be sure, and from the wording of your questions, sounds like you had the same issue.

I'm not Joe, but usually the official line is that you would need to send the entire PLC back to Unitronics for repair. However, Unitronics usually list the manufacturer's part number(s) of the relays in the PLC datasheets, and they aren't too hard to find in stock at general electronics suppliers.

There are examples for this provided with U90 Ladder. To find them, Open U90 Ladder, Go to the "Help" menu Select "Sample U90 Projects..." In the file selction box, open the "Comunication" folder Take a look at the example "Printing Data.u90" Hopefully this will answer most questions.

I suspect no-one uses the ML for ASCII, except for newbies. Visilogic allows you to do it, so yes it should work, but in my experience there seem to be some problems. These probably haven't been found becuase the ML are not frequently used for ASCII. Why? I suppose it seems more efficient, as half the number of ML compared to MI are required to store a string. Also, the MI are generally used for standard programming tasks, so putting the ASCII in ML values keeps the MI area free for other use. This is somewhat a moot point as even the V120 offer 2048 MI values, but to each their own. If I have the opportunity I will make up a basic example for support to take a look at. If I uncover any of my own mistakes I will be sure to post an update.

Does any one have comments good or bad about using ML values to store ASCII strings? I have been debugging an application where the FB Protocol was used (serial), on a V350. It is Visilogic 9.0.1 with the latest publically released OS The app has a CopyBuffer block, copying to ML values, with 4 bytes per linked operand. The vector of MLs is then linked to an HMI display. However when data is received on the serial port, nothing is stored into the vector of MLs, or displayed on the screen. When I manually type some ASCII codes into the ML values, the characters appear on the linked HMI element, so at least that part is working. With exacly the same logic, I changed the ML to MI and it all works fine. So, has anyone else had a problem, and has anyone else got it working?

Using a shielded cable may work, by keeping the noise out. Also try to reduce the amount of noise * make sure the solenoids have RC snubber networks on the coils, to reduce switching transients * use solid state relays rather than mechanical relays. The latter provide some magnetic coupling between the coil circuit and contact circuit, allowing the nasties to conduct back into the PLC. * check that all grounds and commons are connected in a star formation, with no loops to allow noise currents to circulate.

It sounds like electrical noise. What is the PLC controlling?

Hmm, since the system has been installed for several years, and only just started to have problems, can you check if any equipment in the vicinity was added or upgraded recently - such as motor drives, contactors, etc. Also check for modified mains wiring. I guess we have assumed something has changed in the PLC hardware, but maybe something has changed in the environment?

Hello Sparky, Please see attached. Filter with Shift Reg.U90

There are a few of options I have used. 1. Check the features of the Vaisala instrument - maybe you can change the numeric format to have "leading zeroes". That will make the numeric fields always have a constant length. 2. Determine the number of different possible messages based on the different length numeric variables that can be sent. If there are not "too many" different messages then create a protocol scan message for each different option. When the input message is received the PLC will match it to the scan message that fits. 3. If there are too many variations to use option 2, then the only other option is to use the "stream" variable type to catch the string as a stream and decode it using ladder programming. This is by far the more complex option, so I would look very closely at whether you can solve it with option 2 above.

FWIW I have also seen this type of problem. In that case the program had been written with multiple DT operations in a single ladder net. We saw that some of the operations would execute and others would not. Moving each DT operation to its own net solved the problem.

Hi Deke, 9.0.1 was available on the beta site late last week. Meter problem is fixed, but you may need to delete the meter from your project and add it again. Meter looks great when sized up to full screen!

Hello Marko, Quick question: are you using 115,200 baud? This is required, as the enhanced series PLCs always revert to 115,200 baud once the OS has been erased. Also, try powering down the unit, removing the battery and leaving the unit powered down for at least 30 minutes. Then power up with your finger on the (i) key, and try the OS update again. Once all is well you can put the battery back in. DISCLAIMER: I haven't yet powered up a V560 for myself, so am assuming it behaves the same as its cousins.

In general terms that is the right approach. I have a small fan at my desk running directly off the PWM output, with speed varied by temperature. Had to juggle the frequency - too high and it made a terrible noice, to low and it shuddered. If the pump won't be near people, the whining of the PWM should not be a problem.

It's in the BETA download are on the Unitronics FTP site.

Good point Damian, I have seen the same opportunity with the V570, that is not really valid for the smaller units. Also, if there was a Profibus card for the V570, I presume it would also suit the V1040...

I have now given the Beta a run, and also like the higher colour depth. Will this flow on to the colour selection for HMI objects like buttons? I note that the choice is still only 9 colours for 3D buttons and 256 colours for flat objects. Rather than a colour picker with 65536 colours, just the ability to enter the RGB code would be fine... Also, since this update brings 16-bit colour to the V350 and V570, are we any closer to seeing an active USB port on the V570? (I tried it out after loading the Beta OS and it came up in the Windows Device Manager as an Unknonw Device called Test2, but went no further.)

This sounds like an issue with the USB to serial adaptor. Try a different one if you have one, or a PC with built-in CAOM port. If needed, we can supply a USB to serial adaptor that we know will work 100%.

I addition to the signal strength there is also a BER (Bit Error Rate) that the modem returns when queried for signal strength. If the signal is good, but there is a high BER, then it will also fail to initialise on the network. I have seen this cause some problems initialising modems on the bench. I'm not 100% sure what would cause a bad BER with good signal, but electrical interference could be one thing. Going down the track of whether the provider is a factor, are the problems occurring in one geographical area or spread around?

How long did you leave the unit powered down with the battery removed? It seems to take 30mins or so to be sure all residual charge is lost.

Hi Ash, We don't hear much about Ethercat. Knowing a bit about it's evolution from the Beckhoff origins, it seems to be best suited to very high performance applications, like machine tools and other motion control applications. I wouldn't push for it from my point of view.

For me it comes down to the simplicity and elegance of the Unitronics units. Why do users still get excited about a 3.5" colour touch a-la the V350? Maybe becuase it fills their needs in a simple and unique way. IMHO, a screen size above about 12" starts to get away from this fundamental elegance. I would rather see enhancements to the existing range, such as wider range power supplies (10...30V), wider temperature ranges (upper limit of 60 or 65 degrees C) and industrial ethernet protocols such as Profinet and Ethernet/IP. There are plenty of Modbus HMIs available if big is really required. However, if Unitronics came up with a 19" touch with an elegant look and feel then I am sure it would be a winner.

But does it really count if it's done by a Kiwi?

There are port sharing devices available, but they rely on appending a code to each packet to tell the device what serial port to send it out on. This isn't useful for Modbus, unless you want to manually code the modbus packets with the protocol send blocks. As per Bill's post above, I am a little unsure why you need electrically separate networks, rather than separating the pumps using their modbus IDs. Maybe if the unused pumps are powered down do they kill the RS485 comms? Next option, maybe a DPDT relay controlled via one of the PLC outputs?