Simon

The first step is to create a counter to keep track of your cycles. There is no built-in loop counter like the FOR loop. Then decide whether you want to complete all cycles in a single scan, or perform one cycle per scan. I would also consider putting the sequence in a subroutine of its own. Programmers vary in their preference on when to use subroutines. The main goals are to make the code function correctly, and also be easy to understand for someone new. 1. All cycles in one Scan - add a label before the call of the subroutine containing your sequence and place a Jump to Label instruction after the subroutine call. Keep calling the Jump to Label until your loop counter has reached its target. This structure will generate a compiler warning, as it is possible to create a very long scan time with loops that use Jump instructions. The PLC has a watchdog that will stop the PLC if the scan time is too long. 2. One Cycle per scan - call your routine once per PLC scan, until it has executed the required number of times. This is more in line with traditional PLC function, where the scan time is relatively constant. You can monitor the actual scan time from SI 0.

Hello, The cables are very different, so the cable must be changed if the module is changed. Also note that the cable for the EX-A2X has markings on each end to indicate which way it must go.

Hi Flex727, No, the feature I commented on is new, not related your reported problem with the SD card. Se the release notes for V9.5.0 for more details. However it does provide you with an alternative to using the SD card - you can now take all the operand values and save them to a file (an excel file) and then re-load them into a new PLC, all from within Visilogic. Nonetheless, I still think Unitronics should attend to the issue regarding SD cards, as that is also a good option if you don't want to connect with a PC.

And for completeness, we should note that the operand upload/download feature has been added to Visilogic 9.5.0.

Firstly, Unitronics are very careful about consistency and compatibility between versions and upgrades. I would expect the same behaviour across all models of Visilogic PLCs. Unitronics also avoid making changes to firmware that would drastically modify the behaviour of a program written on an earlier version. I have had many feature requests knocked back on this principle. We could launch into a philosophical debate about how timers *should* operate, but... the system is the way it is. If Unitronics change it now, we end up with the exact situation you are afraid of. IMHO it is logical enough that timers only count when they are called in an active subroutine. In my "day job" as well as on the forum I meet many who express disappointment that certain features of Unitronics are not to their exact liking. I try to be diplomatic, but in the end you may need to change your approach to suit the platform, bearing in mind that it surely would have other features that make your life easier. On the final question, yes, the timer will count "n" times faster if you have "n" number of active timer coils linked to the same timer. If you want multiple conditions to activate a timer, "OR" them together first then use the result to drive a single timer coil. I hope this helps.

I agree with Joe, using resistor dividers is a simple way to get a basic measurement but it exposes you to catastrophic damage if something goes wrong. While your circuit is 100% healthy, yes, only a small current flows through the resistors, and the voltage at the measuring point is within the range that the PLC is happy with. However remove one of the 100Ohm pots from the circuit and analyse the result. The input impedance of a thermocouple input is about 10MOhm. So the PLC now becomes a significant part of the voltage divider and you get about 333V on your thermocouple input. The 5.1MOhm resistor is not going to prevent destruction of that input, and perhaps the entire PLC. You also have a safety risk, as there is reasonable chance for high-voltage to enter the low-voltage circuit under fault conditions. It looks like your 500V is DC, which is far more dangerous than the the same voltage in AC. Use an isolated transducer or signal convertor as Joe suggested. I would look for solutions in the following order: look for a programmable transducer, that may give you 500V input and millivolts output Use a transducer with 500V input and 0..10V or 4...20mA output. Use appropriate resistors on the *output* side to drop the signal voltage down to mV for your PLC Use your resistor bridge to drop the voltage on the high-voltage side, then feed that through an opto-isolated signal convertor the PLC. Look for a programmable convertor with the option for mV outputs. For example the WAS4 PRO DC/DC (item number 8560740000) from Weidmuller (www.weidmueller.com) accepts up to 200V input and can be configured for mV output. I won't post a link, as it looks like a temporary link that may not work when you go to click it. Go to the Weidmuller page and search either the description or item number. In any case, make sure the transducer is opto-isolated, and check that the power supply to the module is also isolated from the high-voltage side. I hope this helps.

Interesting question, and not hard to test. The timer only counts down while the subroutine is active. So if the subroutine is called for one scan every second, the timer counts down very slowly. See attached example. If you want the timer to count normally, put it in Main Routine or a subroutine that will always be active. The in your "1 second" subroutine, check the result of the timer to see if it has timed out or not. Timer in Subroutine.vlp

Since you mention that even in the previous configuration there were some failed operations, then it opens up the need to check more aspects. with your program sequence are you allowing time for one operation to complete before starting the next (using the modbus "Function in Progess" bit)? You may also need to insert also a small delay between operations, of 100ms or more, to ensure no bus conflicts. Since RS485 is half-duplex, the transceivers need some silence on the bus to change from RX mode to TX more (or vice versa). I suggest this because you say you had some failures even before this recent change, when using the write operations. What is the length of the RS485 network? What is the cable type used?

Ditto for Joe's comments. it sounds like you are close, the problem seems like a data integrity issue, either with the RS485 termination, baud rate or framing. I didn't look up the 232-485 convertor, but is it one that auto-detects the baud rate and framing or does it have DIP switches or jumpers? As for internal status values in the PLC: SI274-276 Received message counter, serial: may only increment on receipt of a full message, you will need to check. As Joe suggests, try to get a PC on the system, so you have a lot more capability to see what is happening.

Firstly, those values don't normally change without some intervention: * power interruptuions and electrical noise can corrupt these values. * fiddling from machine operators and service people. * a dead backup battery (check the value of SB8) You can provide a fall-back state by making them "power-up Values". This means they can be changed while the PLC is running, but as soon as you cycle power the values get reset to the "power-up value". With a bit more work you could lock them in more rigidly. You will note that the PWM values can only be linked to MI and MB values. However if you use a "Store Direct" you can link those MI values to contstants by storing a constant (#) value to the MI values every scan. Likewise you can force the run MB to be always on by linking it to SB1 (Always on) via direct contact and coil. Both these methods will prevent the PWM values being changed while the program is running, and the constant values are saved into the program where they cannot be edited online. I hope this makes sense.

We have customers who mount Unitronics PLCs in boxes, with batteries and everything to make a stand-alone control box. It is about as "hand-held" as the example above, but then many "hand-held" robot programming pendants are a similar size. The idea of a compact, fully enclosed housing does have potential. We also get asked about "console mount" devices, that can be mounted easily in vehicles, etc.

If you have a second High-Speed counter input available, you can also use that to catch the homing pulse, particularly if you have a very high PPR (pulse per rev) encoder. This method makes it easier to catch a very short pulse, but of course the overall accuracy is still limited by the PLC scan time. Potato, Potahto.

Be aware that the program files holds only the structure and the logic of the program. The other component is the values in the MI and MB values. As Gabriel has mentioned, the PWM output is controlled by 2 MI values and an MB value. If these have lost the original values that the machine was set-up with, then the output won't work. Likewise if you program a new PLC with the existing program, the values will be zero unless something in the program (or a manual setup procedure) changes them. If you go to the "HW Configuration" (hardware configuration) you can view the settings of the PWM output.

Hi Aus, So we have established that you want to use existing equipment, and the items you have aren't the best choices from the point of view of a greenfield design. To have remote access on both PLCs with minimum hassle, you are going to need an Ethernet to serial server. To keep everything on an equal footing, i would get an Ethernet to RS485 serial server, and set up both PLCs on RS485. Make sure you choose an Ethernet to serial server that has a virtual COM port software utility and use this at the PC. In this case the Ethernet/Internet link becomes transparent and you just comm with the PLCs as if they were hanging off an RS485 port on your PC. To handle comms between PLCs, looks like Modbus is the only option. I would use the second COM port on each PLC and the second CAT5 line to do this. Possibly then you need 1 or 2 RS485 to 232 convertors for the PLC(s), depending on their age. As a backup I would put the V230 with Ethernet card in a position where it can be connected directly to the Ethernet end so you can connect the ethernet to that PLC as a backup if needed. You could also use the ethernet port to connect to the V230 and stop modbus, so the single RS485 channel would then be available for remote connection. However, that would not allow you to debug PLCs with the Modbus running.

I took a look at the installation guide for the JZ10-11-PT15. It's a bit of a grey area but I would suggest the following: * the above specification that you quote (20.0-28.8VDC - which is 24VDC +/- 10%) relates to the power supply requirements for the output supply terminals at the right-hand end of the output terminal strip. This is the power required to drive the relays, and is the reference for the PNP solid state output. * If you look at the wiring diagram for the NPN output, you can see that the above 24V supply is not referenced, and a separate "+Vnpn" supply is reference instead. This "+Vnpn" would be your auxiliary 5VDC, and also connect the 0V of the 5V supply to the 0V of your 24V supply.. The on-state voltage of the npn output is 0.4VDC, so it should work. * note the lower frequency of the Jazz output compared to the V350-35-TR34, of 32kHz in NPN mode, when driving a resistive load. As you can see there are a few maybes. If you want to be sure before purchasing the unit i would forward the question to your local supplier and/or to support@unitronics.com

My brief comments as follows: * the NPN outputs of the TR34 are an advantage when working with your 5V signal, as they will work with switching voltages as low as 3.5V (p4 of Spec Sheet) * you will need a 5VDC supply (for example a regulated plugpack (what Australians call them) or "Wall-Wart??" (what the Americans call them)) * The wiring details for the stepper driver are a bit vague, but looks like the step and direction are opto-isolated. Assuming this is the case, put 5V direct from the supply to the (+5) terminals of the inputs, then wire the (-) terminal of each input to the PLC outputs, then connect PLC common to 0V of your supply (and link with 0V of your 24VDC PLC supply). I hope this helps, and please note my assumptions. You may be able to get more detail direct from the stepper suppliers own website.

Also check firewall settings on your PC, turn off the firewall temporarily to start with.

If you are in keypad entry mode (flashing cursor) the key-press events are dedicated to the keypad entry function, so they are not processed by the ladder or the jump conditions. SB39 can be used to force the keypad entries to be complete. Without running a test myself I am not 100% how you would set SB39 from the keypad while a keypad entry is active. But you can use it, for example, to load a screen without having the keypad entries active. Then you can use a keypress to activate the keypad entries (store SI2 to SI2 - see http://forum.unitron...fresh#entry6954)

I would focus attention on the comms hardware. USB to serial adaptors can be problematic. I have found there are 3 "levels" of communication and USBs sometimes only get 1 or 2 out of 3: Level 1: Get OPLC data, online test. Small data exchanges, not very demanding Level 2: Project download. More prolonged data exchange. Level 3: OS Update. Sustained download, very constant binary data stream at high baud rate My suggestion is to change something, the PC, the COM port/adaptor, etc. At worst you may need to send him a USB to serial convertor that you know is rock solid. I have also seen some problems with on-board serial ports, and I suspect they have been subject to the same power-saving tricks as USB serial adaptors.

As I understand your description, one device will need to be isolated, either the Masstrol or the Unitronics, as you will need to inject a source of loop power somewhere. Since we know that the Unitronics is not fully isolated, then it comes down to the Masstrol. If that is not Isolated, i think the only option is to get an external isolation module. If you get the type that supplies loop power as well then you kill two birds with one stone.

For selecting between RS232 and RS485 you only need to change the mode in the COM_INIT block. The Modbus functions (RHR, PHR, etc) do not change. Also make sure you change the Modbus configuration block to point to the new COM port. Unitronics have a convertor (I should have posted that in my previous post). It allows you to use the programming cable and just plug it into the PLC and convertor. The convertor has an RJ11 socket that is pin-compatible with the socket on the PLC. Part Number M90-19-R4 http://www.unitronics.com/Data/Uploads/communication/M90-%20R4%20Specifications.pdf Just check that this convertor meets your needs, note the supported baud rates are 9600, 19200, 38400 bps. If you need to use another convertor, they are available in a variety of termination types, such as DB9 and screw terminals. The cabling required will depend on the convertor.

I think your solution is a good one. Even though you lose some of the nice automation features of the built-in SMS, at least you have full control of the situation.

Is this quite an old modem? I googled it and found a datasheet. It looks like the predecessor to the Wavecom Fastrack family. Have you tried any of the Wavecom profiles that Unitronics do support? I would start with the Fastrack M1206/1306 profile. Another handy tool is the COM sniffer, see link below: http://www.unitronics.com/Data/Uploads/Miscellaneous/Communications%20Sniffer.pdf This will show you where the communication sequence fails. If you keep hitting brick walls I would go looking for one of the modems that is on the supported list.

You can use the port for Modbus, but it will be only RS232. For RS485 you would need an external RS232 to RS485 convertor.

If my memory is correct, that feature was a more recent(ish) hardware revision (maybe in the last 2-3 years). If your V260 is an older model it won't have the jumpers. I have an older V280 that does not have the jumpers.