Simon

That is a different issue, the details on the screen are different. In your case Fernanda, the PLC has lost it's Visilogic project. The most likely reason is that the on-board battery is flat (check the value of SB8) and the project was not originally downloaded with either the "download all and burn" or "Burn upload project" options.

Has anyone had trouble printing from U90 Ladder? It isn't something I do very often, but I wrote a little program for a customer and wanted to print out some key sections. I tried printing to 3 different PDF printers, as well as the office hardcopy printer. I also tried printing via the Print Preview screen. When I hit print it sits there for about 20 seconds, then appears to print something but nothing happens. In the case of PDF print I get no dialo box to enter a filename, for physical printer, there is no printout. Using U90 Ladder 6.6.45 and have run the patch on my PC to fix the recent issue with Windows updates. At this stage it's not a crticial issue but I would be interested to know if anyone else has experienced this, and if there is a simple fix. Thanks,

I expect the loadcell is used to measure the tension of the web. I would have some concerns over the V130 PID being fast enough to control this loop. Happy to have those concerns overturned by the experience of others though 🙂

Hi Nahum, Thanks for the advice. I also did some testing using a PC based Modbus master simulator (ModScan) and confirmed the situation as well. I also found that there was an offset of 1 between the internal UniLogic address value (in the Modbus Slave configuration) and the external Modbus address. For example coil register 9472 appears as 09473 (Read Coils (1)) or 19473 (Read Discrete Inputs (2)) I think it would be a valuable addition to have an explanation of this in the UniLogic help file under Modbus Slave. For example: Coil values can be read using either Read Coils (1) or Read Discrete Inputs (2). For example coil address 4444 can be accessed as either 04445 (Read Coils (1)) or 14445 (Read Discrete Inputs (2)) Register values can be read using either Read Holding Registers (3) or Read Inputs Registers (4). For example Register address 1111 can be read as either 41112 (Read Holding Registers (3)) or 31112 (Read Inputs Registers (4)) Maybe add a configurable offset value to UniLogic, so this offset can be corrected in future applications, without destroying backward compatibility?? It has always been a common "gotcha" with Modbus, to discover who counts from "0" and who counts from "1". Thanks, Simon

Hi Jota, thanks for the reply. I expected more people to jump on this. I also found the offset of 1 between the PLC address and the SCADA address. In my case the customer had a list of SCADA addresses they expected to see, so in practice I needed to subtract 1 from the SCADA address to get the internal PLC address. I had no trouble with using the Slave ID of 255 on both the PLC and the SCADA. I did my testing using ModScan. More details from me below. Simon

In helping a customer integrate a UniStream into a SCADA system I have come across a curious gap in the available information. I can't see any declaration of the function codes that the external Modbus master must use to communicate with the UniStream as a slave. The Unitronics example and tutorials use a UniStream as the master as well as the slave, which doesn't highlight this issue. I have looked within UniLogic, tried exporting the Modbus registers as excel, looked at the UniLogic help file, watched the Unitronics YouTube video and searched the forum. None of these sources gave the necessary information So far I have gleaned that the following codes are supported on a UniStream modbus slave: Coils Read Coils (function code 1) Write Coils (function code 5) Write Multiple Coils (function code 15) Registers/Words Read Holding Registers (function code 3) Write Single Register (function code 6) Write Multiple Registers (function code 16) But what if the customer's master only supports Read Input Registers (function code 4)? I don't have a firm answer on how we could handle this. Can anyone provide a definitive list? I would like to be able to answer this question with confidence. A standard part of documenting a Modbus Slave is to specify which function codes it supports, so the master can be correctly programmed. Thanks, Simon

Perhaps this is incentive to power up and test before heading to site? However I know there will be situations with remote sites and urgent breakdowns where this feature will be a major pain *if* it is made mandatory. There is the option of using a mobile and an app, but there are still some parts of the world where there is no mobile phone coverage. We have customers who like to put PLCs in those places. It's always a challenge doing dubugging over the phone when the person on site needs to walk (or drive) 10 or 20 or 30 or ??? minutes from the PLC just to make a phonecall. I notice in the link above: "At present Activation is not mandatory, and will not restrict the controller’s operation. Activation may be made mandatory at a future date."

Yep, understood. You could email support@unitronics.com, let them know you already have the distributor working on it, and also copy the distributor. That way you don't get two lots of people working on the same problem and you can get some direct feedback on any technical points that Unitronics may be able to add.

Just on your question of a "direct line" - the sort of question you are asking about batch QA issues has both commercial and technical implications, so your supplier/distributor would be the best contact as they can handle both aspects. It sounds like that is already happening. In general terms you could email support@unitronics.com (or use the support portal) to communicate the technical issue to Unitronics, but the resolution is likely to still involve your local supplier/distributor. I hope that helps,

Wow, really thorough testing! It looks to me like a hardware fault. It does happen, out of the thousands of units I have sold, I've seen maybe 2 or 3 with that specific problem. Before I worked with PLCs I worked with single board computers, and saw similar (rare) problems with them. My prediction is that no amount of software testing and resetting will fix this. But happy to be proven wrong (for your sake) ?

The status information is accessed using a ladder function in the V700. From the help file: I found this topic by searching "v700 ethernet" in the help.

Hi JJ, I have a few questions: * When you say it is connected to Port 2 of the V570 - do you mean COM2? Does the thermocouple have a Serial/Modbus interface? * The post by Flex727 is correct, the E2B snap-in module doesn't take thermocouple inputs directly. It would need a signal transmitter, typically this converts the thermocouple interface to 4...20mA current signal. If you have a datasheet for the thermocouple and/or any photos of the device and the way youhave it wired up, please post.

Just managed to help a customer get the UniStream talking to an SMC EX600 module via Ethernet/IP. The original post above was helpful, so thank you @Pista :-)

I've just encountered the Run Idle as well. Looks like it is an optional 32-bit header from some google searches I have done. I did find some additional details in the UniStream help file by searching for "idle":

U90 Ladder shows the +/- 10V notation, so I would say that is definitive. For the record, the IO-AI2-AO4 expansion module also has +/- 10V outputs (Jazz does not support expansion modules).

With UniStream you don't need to use the linearisation block, the analogue input configuration does it for you. See details below, this will scale the 4...20mA input to 0...10,000 as an integer value. There is no need to understand the min/max range of the digital input (or output) word (of course you still need to know if the hardware resolution is high enough to measure the value accurately). Set up the analogue input hardware config as follows: The only downside to this is that the scaling is a literal constant - you can't vary it during run-time. You can still use the X1, X2, Y1, Y2 method and linearisation block if you need the flexibility as it will allow you to use variable tags as your linearisation points. You might do this if you wanted to do field calibration in the PLC. BTW, when you first open the properties box above, the "To" field shows the range based on the native resolution of the analogue input (for example 14-bit = 16383).

As above, the resolution will not prevent you from getting a reading. You mention 2-wire transducers. Firstly just work with the Oxygen transducer, as I assume it is a 3 or 4 wire device? I would expect the Jazz to read it fine. If you are including the 2-wire devices in the IO wiring they may be interfering with the readings. Also when you say you "couldn't get the measurement" what does that mean exactly? Was the value 0, 1024, 32767? Did it vary at all when the oxygen level varied, even if it was the incorrect value? With the 2-wire devices, the Unitronics PLCs do not provide loop power for 2-wire analogue transmitters. You will need a power supply for loop power and the best way to do this is to use an isolation module with loop power capability.

Are you doing anything special with screen jumps, for example using ladder functions to jump between HMI screens? It sounds like the unit is flipping between HMI screens.

I would make a couple of comments: This is not good practice for safety engineering. The way you have it, the PLC is in between the safety contacts and the downstream equipment. For example, if the PLC failed (for any reason) and put 24V on the outputs (say from an internal short circuit), the safety contact would have no effect. A better circuit would place the safety contacts *after* the PLC outputs, and yes you would then need 3 contacts. I say this is a "better" circuit, but it still may not be the correct circuit for your application. You would need to check your local safety regulations and follow all requirements of those regulations. With the problem you are experiencing with comms loss, I suggest it would be an EMC disturbance resulting from the sudden loss of power to the PLC output circuit and/or the drive it is controlling.

FWIW, a "proper" RJ45 to DB25 convertor isn't a "get out of jail free" card. It might help hold things together but you still need to know where the pins are going. As Ausman said, testing is key and the basics are RX, TX and Ground, and turn off hardware handshaking. If you can't turn off hardware handshaking then a loopback is needed on the handshake lines.

The Jazz contains a built-in USB to Serial convertor.

Without having looked at the details, I would go with serial interface (RS232 or RS485). Usually they just accept a simple ASCII string and display the numbers.

Just to make it 100% clear, the Jazz and M90/91 series don't support 115k baud. You would need a model from the enhanced vision series (for example the Vision 700), or the Unistream

I agree with all of the above - sounds like "dirty" power. Another place I have seen this type of behaviour is on vehicles, where the PLC is directly connected to the main electrical system. When starting the engine the voltage dips way down, and vehicles have a lot of spikes from the operation of the battery charge regular and large auxiliary loads. Since you already have a switch mode power supply, which will be filtering out some of the transients and fluctuations, the next step in that direction would be a small UPS, either on the main side or the 24VDC side.

I would stick with the separate power supplies as you have them. The CAN comms power supply is isolated internally, so using a separate power supply maintains this isolation. Just to check, is the 0V of the CAN power supply connected to ground or 0V of the PLC supply? I believe it should be floating, that is not connected to the main system 0V or GND. I think this then puts the focus on what is happening at the EX-RC1. Check the datasheets, as I know that for some modules Unitronics ask that the 0V rails of the different power supplies are connected together. Hope this helps.