Simon

We had a reported problem with this last week. I haven't seen the PLC to try it myself. As Jas mentioned, baud rate is the first thing I would look at.

If you link the actual timer rather than the MI value, you will have many options, see below:

In general terms UDP traffic should co-exist quite happily with TCP traffic. This is what happens on the internet all the time. WIth TCP the data is acknowledged and re-sent if lost. However with UDP the data is simply sent, with no ack or retransmission. The UDP traffic will most likely suffer first if the network becomes congested, since there is no acknowledgement. This also means that UDP will impose less overhead on the network as it doesn't generate the additional traffic required for acknowledging each packet. If you need some form of "i'm alive" signal back from the UDP slaves, then you should include this in the logic of your Visilogic projects.

OK, so after a few false starts, it is working. It looks like the above quoted comment from the help file was cut and pasted from the ModbusRTU help section. As discussed above, UDP is the simplest setup. Also In the master modbus config, set up a slave definition with IP address of 255.255.255.255. Provided there is only a single modbus slave device at each IP address, then leave the Slave ID at 255. Use this slave when sending the data to be broadcast. Set both master and slave sockets to use UDP See attached programs, they are very basic, just enough to show that this works. Visilogic version was 9.2.0. One master (V570) and 3 slaves (V130, V230, V530) Modbus UDP Broadcast V570.vlp ModbusUDPSlaveV130.vlp ModbusUDPSlaveV230.vlp ModbusUDPSlaveV530.vlp

When you say the Help file, I presume you mean: You also need to have the correct network configuration to support the broadcast. If you are using 4 slaves or less, you can use TCP connections, and you must establish a separate socket connection to each of the slaves before initiating the broadcast. If you have more than 4 slaves you must use UDP, in which case you don't need to perform any socket connect functions, as UDP is a connectionless protocol. I am setting up a test and will post my results.

Hi James, It's not possible to open two projects. However you should be able to copy to clipboard, close the project, open the other project and then paste. I know this isn't as simple as we would like but it is at least an option.

Colour LCDs work by filtering the white backlight to produce colour. The backlight is always on and the active LCD layer is used to block or allow light to pass through the red, green and blue filters. Each pixel is a group of these filters. For example the red colour is produced by switching on only the parts of the pixels with red filters. One weakness of LCD is that when the pixels are switched off a very small amount of light leaks through, so in the case of red colour, there would also be a very small amount of green and blue emitted. THis would also be the case for the "black" areas of the screen. As Emil suggested you can also adjust the backlight intensity to its minimum usable level. If they use B&W mono screens then it sounds like some stray light is OK. But maybe they have a way you can run some tests?

Hello stembera, Contact your local distributor for their help. It isn't a repair that can be carried out locally. (I work for the Australian distributor of Unitronics)

Hi Reuven, When checking comms to the PLC it just brings up the progress indicator and hangs in that state.

Hi Alan, That temp range should not cause any problems. Please email me through my profile if you want to discuss options to get this fixed.

I am interested to hear of user experiences with the EEEPC and Windows 7, and Windows 7 Starter in particular. A user has had no problems with Visilogic, but lots of problems running UniVision licensing, particularly with USB to serial. I look forward to hearing of scuccess or otherwise using this combination.

FWIW I powered one up on the desk with no addtional housing, just the PLC as shipped. Ambient is around 20-22degrees and the reported temp on SI14 rose to about 28degrees. So the offset from ambient is not unexpected, but the large variation is less easy to explain. My reference is an old V120-12-UN2 with a thermocouple attached.

Hello Alan, It's not a common problem, but is unlikely it could be repaired on-site. The only user-accessible setting is the backlight intensity SI value, which you have checked. I don't know the specified lifetime for the backlight, but you should expect many years. This will be less if the unit is exposed to temperatures outside the operating range, particularly at the higher end.

Hello Stein Although I didn't ask the original question, let me point out that the question relates to the use of the internal temperature sensor, accessible via SI14. The snap-in module is not being used to measure temperature.

OK, so sounds like something is not right. Do you have any V570 units that record the correct temperature (or close to it)? Are you saying that you have two V570 plcs that are showing temperatures that are both way off, and they are also quite different from each other?

Just a simple check, make sure you are using 57,600baud or lower. Newer versions of Visilogic will default to 115,200baud. The V280 will start to communicate at that speed, but will lose the plot at some point.

Hi John, The V570 develops more heat than some of the older models like the V290. If it is locked in a box the internal temp may get noticeably higher than ambient, particularly if the box is sitting face-up rather than vertical. Does this tally with what you are seeing? Simon

Thanks Cara, but that one seems also to be suffering the same malaise. I have the 9.2.0 beta, so will wait a couple of days and try again.

Looks like everyone is downloading...9.76kB/sec. Maybe the server needs a cigar and a good cup of coffee?

I think it also occurs in choc-coated peanuts.

Hello MWD, The data table is stored in battery backed RAM, the same as the MB, MI, etc. If it is being lost when power is switched off there must be a problem with the battery - either not-fitted, is flat or the unit is faulty (the latter is least likely, but one of the possibilities). SB8 will tell you if the battery is getting low. Since the V130 supports the SD card, you could use that.

In my experience, remote access via GSM modem for the colour PLCs is quite slow. Possibly the response may be slightly faster using Remote Operator instead of Remote Access. However the fundamental problem is that the baud rate via GSM is only 9600. The ideal solution is to use a broadband wireless modem connected to the PLC via ethernet. If you are stuck with the GSM serial modem, another option may be to use SCADA software and Modbus.

After a lovely chat with our friendly Unitronics Desk Manager about promoting the new V1040, I sat down the next day to prepare our demo box for a trade display and realised it only has the V570 fitted! This is the Unitronics factory demo with the V570, V350 and Jazz. After some quick action to find a piece of panel material, the afternoon was spent cutting and soldering to migrate the existing V350, Jazz and peripherals to a new panel that also accomodates the V1040. The modem was moved inside the box, internal cable ducting was ditched for a more "free form" approach. Program changes were minimal, mainly to stretch the HMI screens to the new resolution. Some of the graphics did not re-scale well, but as time was not on my side they will have to do for now. Some screens are yet to be modified and the documentation pages needs updating with the new products. However all in all it was a good result for a last-minute re-build, and now we can have the V1040 proudly on display.

I get it when messing about with Bluetooth serial ports and modems. If Visilogic tries to open a COM port that is associated with a Bluetooth modem, the modem must be initialised, or it all goes down in a heap. I have had a similar experiences with a virtual COM port, but after the first time I just avoided the situation, so don't have much info on that one.

Hello Fabio, I think you are doing a good job of finding all the problems! If you are using a standard input then the fundamental limit is the speed you can read the input. This is either the normal PLC scan, or you can use the 2.5ms or 1.25ms interrupt routines (depending on the model of PLC you are using). This still isn't fast enough for your pulses, based on the figures you provide above. This is the problem for the high-speed range. You have already looked at the low-speed range and ruled out using more bolts. However that is really the only option to improve resolution for low-speed frequency measurement using a high-speed counter. Here's a thought. Note that when you configure an input as a high-speed counter, you can also still read the immediate value of the input, as a normal digital input. For low speeds you read the input directly in logic, as you have been doing. Then for higher speeds you can read the High-Speed input. There are definitely some potential problems with this approach, but maybe it's just crazy enough to work...