Simon

There is no need to buy a new serial card. The issue is with how the DB9 connector is terminated. One option is to see if you can purchase an MJ10-11-CS76 from your local distributor. This is for serial modems, but also works quite well for other devices that have a standard 9-pin female serial port. You may also be able to get it working on the MJ10-22-CS25 if you use a null-modem cable between that plug and the scales. In both cases turn off hardware handshaking (or hardware flow control as it may be called) on the scale. You can make a cable direct from the RJ12 modular plug to DB9, but even if you know what you are doing (and have done this before) it can be confusing trying to get the right pinouts on the RJ12 connector, so take your time and don't panic.

All the Unitronics units are programmed in Ladder. However the Vision family has several function blocks as well, that are inserted as ladder elements. Since you are using a HMI panel, then possibly the V130 or V350 are a better fit than the Jazz. With either the Jazz or V130/V350 the one software package is used to program both the ladder and HMI screens, which should give you a saving in time and complexity. Software is free to download: U90 Ladder for the Jazz Visilogic for the V130/V350 Programming cable is as follows: JZ10-11-R31 - purchase JZ-PRG (Or JZ20-R31 has a USB programming port, the JZ-PRG not required) V130/V350 includes serial programming cable, you need a physical RS232 serial port or USB to RS232 adaptor.

It's a while since we set up a landline link. If you can figure out the details, such as Joe posted, then it is good to have that knowledge. We always followed the less subtle method of only using two identical modems, which makes it simple.

This can probably be solved by cascade control. Use the CV of the Body Temp PID as the SP for the Cable Temp PID. So when the Body temp drops, it asks the Cable Temp PID for more heat (and vice versa). Tune the cable temp PID first, without the Body Temp PID active. You will probably also need to add a limiting function to the Cable Temp PID to restrict the output if the PV gets too high, as a software limiter. Use basic Compare blocks for this. Note also that there is a PID function to suspend and reset the Integral term, and these need to be used if the limiter is active. I can't get into this too deeply, but I hope these ideas give you some leads to follow.

The snap-in I/O modules are strict about supply voltage, and it needs to be 24V. For example, with digital inputs the switching thresholds are based on 24V, so 12V applied to a 24V input will not be enough to switch it on. The threshold is usually around 17V (this is specified in the datasheets for each module). There are issues with digital outputs as well, but I won't blabber on and on. As Eyal mentioned you can use the V120 and select a model that has 12V capability (usually controlled by jumper settings inside the unit). Alternatively, if you want to stay with the larger PLC then you can use expansion I/O on 12V. You need the special "-L" versions, look at the listing of I/O modules on the Unitronics website for those. The only issue I have had with the 12V operation is the lack of analogue outputs. In the M91/V120 families, none of the models with analogue outputs have a 12V option, they are 24V only. When looking at the "-L" I/O modules, there is also an absence of analogue output models. The final option is to use a 12V-24V step-up convertor and run your automation logic on 24V. Note if you have relay outputs on a 24V module, you can still use them to switch 12V directly, but you would need 24V power for the relay coils.

Have you installed the UniStream software before plugging in the controller? As far as I am aware, the driver is installed with the software. Having said that I have seen a similar problem on Windows 8 even after installing UniStream, so I am especially interested in what you encounter.

Sorry, just looked at your screenshots, realised that some of my comments are moot, in particular, you have used a transitional contact for the inits even thought you have added a socket init, it matches the default settings, so it should work fine (though I would still suggest deleting it and relying on the default setup, for simplicity).

Further comment, to ping the PLC from the PC, you don't need to set up an ICMP socket on the PLC. It should respond to ping requests in its default state. As far as I am aware the ICMP socket setup is only needed if you want to ping another device from the PLC. If you aren't getting a ping response then there is something wrong at points 2 or 3 of Flex727's post above. If you have added TCP Socket Init blocks I would remove them (but leave the Card Init in place), because, as several have posted above, the default socket configuraiton will respond to PC communication requests. Removing any blocks you have added will ensure you have the default configuration. Re-download and cycle power to the PLC. Also make sure your initialisations are triggered with one-shots, not "always on" conditions. Also try disabling your PC firewall (if you have one).

The V570 T20B units are specified for 12/24V for just the PLC/HMI without I/O. The older style T40B with cold-cathode backlight is only 24V. In general, any of the PLCs without I/O can run on 12 or 24V, including the V130-33-B1 and V350-35-B1 (and their "J" equivalents). It's the I/O modules that are more particular about supply voltage. For example, with digital inputs the switching thresholds are based on 24V, so 12V applied to a 24V input will not be enough to switch it on. The threshold is usually around 17V (this is specified in the datasheets for each module). There are issues with digital outputs as well, but I won't blabber on and on. Also, in the M91/V120 families, none of the models with analogue outputs have a 12V option, they are 24V only. When looking at the "-L" I/O modules, there is also an absence of analogue output models.

Hi, I would suggest using 24VDC. Either use a voltage booster (you can get these from automotive accessory suppliers and electronics stores), or use two smaller lead-acid batteries wired in series, like alarm or UPS batteries. If you really need to use 12V, there are only certain models of M91 you can use. You will then need to make some compromises about the types of signals you can use and how you will interface with the motors and sensors. With 24V you can use the Jazz series. For example if you use the JZ10-11-PT15, my comments are below starting with ## - Set/ Operate a (stepper or geard) motor to spin the spit in a clockwise and counterclock wise direction. ## you can use the HSO (High speed output) on the Jazz to control the stepper (through a controller/amplifier) and have direct speed control. Use a normal digital ouput for Fwd/Rev selection. Just check pulse rates and gearing to make sure you can get the RPM you need from the combination of Jazz and stepper. - Set/ Operate a (stepper or geard) motor to raise and lower the spit. ## use a digital output for simple on/off control, use a fixed speed geared DC motor. - Measure and display 2 anolog temperature sensor readings ## purchase PT1000 probes that can connect directly to the Jazz unit without needing an interface module. - Measure and display the speed from a tachogenerator ## use 0...10V analogue input to read this signal (depending on the tacho used),. This PLC also has a pulse input, for pulse style tacho signals. The LCD display can show the value. Note that if you use a stepper, and have no pole slipping, then the rotational speed is determined by the speed of pulses to the stepper and external feedback is not required. - Contain programable "set time" operations ## easy in M91 or Jazz - Contain display with time of day and other varibles. ## generally easy in M91 or Jazz. You can run into other unforeseen limitations with the Jazz, so another option is the V130. For example the V130-33-TRA22 has just about everything you would need built-in, with more flexibility than the Jazz. I hope this helps.

As I understand it, the Reload function of resetting the counter to zero should happen without needing an interrupt. It is done purely in the I/O module I have tested his in the past, and that is how I remember it. The interrupt is only used if you also want to do other functions. Using the interrupt to reset the counter has the potential to lose counts at higher speeds. Please test what I say here, I am willing to be corrected if this is not correct, I don't have time to wire up an encoder to test. There is also the chance that you are losing counts due to a bad waveform on the pulses from the encoder. This becomes more noticable at high speed. You can test for this by using a much shorter cable. Also an Oscilloscope can let you see if the waveform from the encoder is nice and sharp or distorted. When using an oscilloscope to view the signal, try to turn the encoder at a constant speed.

It looks to me like this: * you have two variables, temperature and pressure. * I assume the boiler is on/off control, not proportional? The boiler control is potentially a 3rd variable. * in the first case you controlled pressure to a setpoint, and allowed the temperature to do whatever. * in the second case you want to control temperature and have some constraints on pressure. So in the second case you may be looking at a cascade control loop. To do that, leave your existing pressure loop unchanged. Then create a second PID loop for temperature. The CV of the temperature loop becomes the SP to the pressure loop. So if temp drops the Temp loop issues a command to the pressure loop for more pressure (flow). You will need to set the constraints of 3-5bar as min and max limits in your pressure controller. You will also need to suspend any integral action in the Temp loop if the pressure loop hits either the min or max limit. Otherwise you will get integrator windup in the Temp loop. You should also set the update time/sample rate on the Temp loop to be 10 times slower than the Pressure loop. You may be able to approximate some of this, for example by using a single PID controller with temperature as the PV and pressure/flow as the CV. But without knowing your system I can't way whether this will be stable or not. I hope these comments are helpful, I can't go much further into the details, as I don't do this type of control everyday (it was something I did in a previous "life"), and don't have the time.

You should have no trouble logging this to internal Data Table memory at 100Hz. Not sure about logging at that rate to the SD card. But you could log to internal memory at high speed and then transfer the data to SD card a block at a time. The timebase on the trend sampling only allows you down to 100ms resolution, so the fastest sample rate for the trend graph is 10Hz.

Thanks Saragani, I 'm sure the UniPics Icon was not there when I first tried it, but it is there now. I can't recall whether I rebooted immediately after upgrading to 1.2.5, but I suspect that maybe the link was put in once I rebooted.

One other thought, its a while since I played with this, but if your system is likely to turn in reverse, just check how the reload behaves in that case. I seem to recall it being necessary to swap the sign of the reload value (make it -1440 for negative rotation)

I think the error is in the timing of the reload, as the PLC scan is much slower than the incoming encoder pulses. You should get the result you want if you go into the hardware configuration of the high-speed counter, and change the configuration from a normal "High-Speed Input" to a "High-Speed Input (Reload)". Make sure you remove the original configuration, so you only have one configuration for that input. Put 1440 as the reload value. When you use the hardware configuration like this, the reload is executed at the speed of the I/O hardware, not at the speed of the PLC software scan. As for your incoming pulse speed, I have always understood the limit to be on the physical pulse speed. So 20kHz is 20kHz, it doesn't matter whether it is a 2-channel quadrature signal or a single-channel pulse. I am happy to be corrected if this is wrong.

It seems I'm missing something. The latest update notes indicate an expanded range of images in UniPics. However I can't seem to find UniPics on my system anywhere. I have updated to UniLogic 1.2.5. It appears the pics should be in the location: C:/Program Files/Unitronics/Unilogic/UniPics (or similar) but I can't see anything like that. Can anyone help?

Can I make some additional comments. Firstly you can monitor the actual PLC scan time using SI0. This is only in units of ms so it can show zero if the scan time is less than 1ms. If you want to get more resolution refer the following topic: http://forum.unitronics.com/index.php?/topic/106-scan-time/?hl=scan+time and in particular Emil's post: You will find that a typical scan time for a V570 running with no ladder logic is about 500microseconds. I don't really know how to apply the quoted spec of "9usec/1K of program size.". There seems to be a base scan time, irrespective of the ladder code. Perhaps the 9us/kb is the additional scan time due to ladder code, I have never really figured that out. However the scan can also be influenced via HMI loading.

I don't think anyone would think you stupid, it's a steep learning curve trying to figure this out from the beginning. What you have posted looks OK, from a quick glance. Once you have it working the PLC will collect the PGN data from the field, capture the 8 data bytes of the PGN and save them to the memory operands you have nomiated (which is not in the screenshot you posted, you need to scroll down). Make sure you allow 8 bytes of space (4x MI or 2x ML or DW) otherwise your data will be messed up. For example if you nomiate MI10 as the pointer target, also leave MI11-13 unused. I suggest giving them labels so the system sees them as occupied. After that it is up to you to read out the bits and bytes from that 8-byte data block, based on the SPNs that are defined for that PGN. I would put a counter on your receive bit (MB0) and reset it every time it goes high, so you can see if your are receiving data. If you have a colour PLC it has a built-in CAN bus monitor, that lets you see the raw CAN data from the Info mode. (I have had only a quick try with J1939, so am happy to be corrected on any point )

Note the new UniLogic 1.2.5 is up, with some smokin new features!!!

I don't recall experiencing this. Since it sounds like you have a V130 and a V350, I suggest setting one as master and one as slave. Then see if the limitation still exists when reading from Unitronics to Unitronics. (Or in general, try it with a different slave, other than the simulator).

this usually happens if the timer coil is being called twice in the same PLC scan. Check to see if the coil is used twice in your program or you are calling the subroutine twice, or a combination of both.

Make sure you use the right shortcut when starting a swapper version. If you install, let's say, Visilogic 9.5.0 from the web it will create a start menu shortcut. If you then swap to 8.0.1 the original start menu shortcut won't work as it still points to 9.5.0. The way around this is to click "yes" on the option at the end of the swapper process to "Create shortcut to registered verison on Desktop". However make sure you keep deleting the old shortcuts to help you keep track of which one is active.

I might be coming in a bit late on this one, but I prefer UniCAN to link the PLCs in this way. The main advantage is that UniCAN can be event-driven from either end. Modbus must be polled using a master/slave arrangement. With UniCAN either PLC can send changes to the other PLC as soon as something happens. Also the CANbus hardware is on the V1040 PLC as a built-in option, which leaves your serial ports free for other uses. On this final point I am willing to be corrected, but I also think the CANbus physical layer is slightly easier to deal with than RS485. Just follow the rules, use the proper cable and it usually works. RS485 works well once it is up and running, but can be difficult to figure out initially. As with Modbus, there is a webinar: http://www.unitronics.com/support/webinars/canbus-unican

I have assumed the boot time would be reduced with ongoing development. It would be good to have some feedback.