Simon

Just as well I wasn't holding a coffee over my keyboard Cara....

What program have you started with to write the Jazz Modbus program? The standard U90 Ladder example is written for the M91 and won;t work on a jazz with the MJ20-RS4 (JZ-RS4) comms adaptor. You need an additional Com port ocnfiguration step. Please see screen shot below for the critical step, added after the Modbus config rung. I have also attached the sample project files. I think these file was originally sent to me by Unitronics support, but IMHO they should be in the U90 Ladder examples. Modbus Slave Jazz RS485.U90 Modbus Master Jazz RS485.U90

Having spare modems and testing in a "safe" environenment is a very good idea. Nothing worse than waiting until you are on site before trying something new...

I would say most forum users (myself included) would not know what a Delta Robot was. Here is a link: http://www.sigmatek-automation.us/pdf/eng_delta-robot.pdf If you are planning to drive the actuators directly, polar coordintate calculations would be required for the kinematics. There are no built-in kinematic functions in the Unitornics PLCs, but they do have a limited amount of floating point variables and a full set of trigonometric functions. Depending on your machine setup you may be able to store all the desired trajectories as lookup tables rather than generate them on the fly. This would allow you to calcuate the trajectories offline on a PC and just transfer the final data to the PLC data tables. Either way this would not be a simple project.

But if the PLC has put itself into stop mode how can it then set SB24 or SB300? I think the original question was asking can this be done without user intervention. Kind of like a self-resetting watchdog - if the PLC goes into stop mode, automatically reset it. Possibly you would want a limit on the number of times it would self-reset, so if the fault was permanent the PLC would stay in stop mode after a certain number of reset cycles. Note also that if the PLC is being remotely monitored, SB302 will indicate if the PLC has gone into stop mode, giving the possibility to reset the PLC via remote connection.

It is possible to set up the PLC GPRS connection in listen mode, but I haven't done it. However you now have the same problem turned around the opposite way. Once the PLC has registered on the GPRS network you need to know it's IP address. So have it send you it's IP address via SMS before putting itself into GPRS listen mode. You probably need a GPRS_RUN FB in there somwhere as well. Another gotcha is that the cellular provider may block incoming requests to the GPRS device, particularly if they come from outside the cellular network. If it doesn't work from an ADSL (or similar) cable-based internet connection, try connecting with another GPRS modem using the same cellular provider as the remote PLC modem. Remeber that the main commercial use for GPRS is internet browsing on mobile phones - so teenagers can do important things like get on facebook and download ringtones.

I haven't done any relative comparison. However, the programmer who triggered this post has generously provided the following feedback: So the screen does affect scan time, but this suggests it relates more to the number of variables rather than the size of the screen. 4ms still looks pretty good for any general purpose PLC task.

Flavien: SMS will work fine at the higher baud rate since it just involves comms between the PLC and the modem (then the modem "does its own thing" as far as sending the SMS onto the GSM network). It's just the dial-up connection that seems to work best at 9600 since the "over the air" data rate is limited to 9600, and there is an end-to-end connection involved. TT-ZX: If you use GPRS you can use SMS on the same modem. There is a good example for GPRS in the Visilogic help files. Basically you use SMS as the primary method of communication with the PLC. When you want to set up a GPRS conneciton, send the PLC an SMS to initiate the GPRS connection from the PLC end. When you are finished with the GPRS connection, either terminatie it in the PLC from the remote connection or have a timout on the PLC that drops the GPRS once there is no host connected or no data for a certain period of time. The limitation is that you can't send or receive an SMS with the GPRS connection active. For this to work you also need to set up port forwarding in your PC internet connection, and know what the current public IP address of your PC broadbnad modem is (or pay for a static IP address on your PC connection). If you go the route of using an Ethernet broadband modem, then SMS is usually not an option. We have a customer who has tried in vain to find an ethernet modem that also has a serial port that allows SMS. One possible option is to use email instead of SMS.

Not sure how it works elsewere, but in Australia the network sets the baud rate for dial-in (CSD) GSM connections at 9600baud. Since GSM base stations are only made by a few manufactuers, I presume this is going to be reasonably consistent across the globe. I have tried setting the modems to 57600, but it does crash out. I presume the 9600baud GSM link causes timeout and/or buffer problkems with the 57600baud local serial links For high data rate the other options are to use a Packet Switched Connection (like GPRS) or use a stand-alone broadband modem with Ethernet (and fit ethernet to the PLC).

A lot of my time is spent explaining/verifying/demonstrating. The attached program shows the scan time for a V1040/V1210 and also demonstrates the logic required to do the same for any of the Enhanced family of PLCs. ScanTime Tester.vlp

Are you trying to save to a USB stick or network drive? You need to save directly to a physical disk. That's one possible cause.

Hello Jason, Go to the Tech Library section of the Unitronics website http://www.unitronic...chnical_Library there are specification documents for each model, and usually in the section on analogue inputs there will be a conversion time. The final sample rate is a function of the conversion time and PLC scan time. If the conversion time is longer than the PLC scan, then it will determine the sample rate. Otherwise the PLC scan time will determine the sample rate.

We have also been doing some work with email on a V130 using GPRS and we get the extra characters. It hasn't been a big issue but would be nice to get rid of them. We have used a couple of different providers, and from memory it occurs with both of them.

HI Cara, It looks like your response is steering in the direction of zooming out rather than zooming in. In the case I was dealing with, the customer didn't want to zoom out so he can see all the screen. He wants to be able to zoom in on a smaller area so he can see in more detail. So it would probably require a combination of zoom and scroll, or the ability to select a window of the display and zoom in to it.

I have also had a user request this. I think it would be a valuable addition.

At present the only thing I am aware of that comes close to this is the ability in the Remote Access utility to read/write the entire memory of the PLC to/from a spreadsheet. So you could create a spreadsheet from a new (or freshly initialised) PLC, with blank values, then enter your one-time initialisation values. After download of the project you then update the operands in one step using this spreadsheet. I know it is a bit of double handling, but it is less steps than setting each value individually, and also provides more certainty that you won't miss something. I would like to see this built-in to Visilogic, both as a programmer's tool to set initial values, but also as a service tool, so on project upload the live values are also copied. The latter would allow very simple replacement of an operating PLC in the field.

I doubt the cable is a problem over such a short distance (though some may disagree). I have had CAN working over several different "non ideal" cables, though usually just for testing. However I would always recommend using the specified cable type for a permanent installation. Also, if the communications is working in one direction, that would indicate that the cable is transmitting the data OK. Check things like your unit IDs and CAN status bits and integers. What is triggering the send that fails to be received? If you are trying to send too fast there will be problems. If it is event-driven, check whether you have a vibrating/bouncing contact or fluctuating analogue signal that is triggering a send more frequently than you expected.

Hi Cara

Here 'tis.

I took a quick look and the Modbus Read Holding Registers function allows you to assign DW as the Master Start of Vector. So you should be able to drop the unsigned 16-bit values directly into DW operands, which are 32-bit unsigned type. That sounds like a solution, but give it a try first.

You can purchase external displays with a serial interface. ASCII text is common, you may even be able to get Modbus. The link below is an example, these guys have a very high standard of product, with a price to match. You should be able to find similar products from other vendors if this one isn't in your price range. http://www.siebert-group.com/en/index.php

It sounds like you need to create an image cache file. This can either be created from Visilogic or from the PLC. If you create from Visilogic, save the file to disk then import it into Remote Operator. If you create it directly in Remote Operator, it retireves the images back from the PLC and creates the file itself. This can be slow if you have a slow connection and/or lots of kB (or MB) of images. Hope that helps.

From one of Ofir's posts in the old forum: These operands are not tagged in U90 Ladder with any description.

Hi Nacho, I have been requested for BACNet comms a couple of times also. My initial impression was that the physical layer of the communications would be the main problem. However if BACNet can operate on RS485 then that obstacle is removed. The next question would be to make sure the target devices are using RS485 compared to the other types of physical layer available. Once the question of Physical layer is resolved, the next issue is implemention of the protocol. As per Keith's post above, I don't see an easy off-the-shelf way of doing this directly out of Unitronics. If you can obtain a BACNet slave to test with, maybe you can get a limited number of messages working. Unitronics protocol is generally quite flexible. A couple of areas have caused me concern: * use of the NULL (0x00) character as a string terminator. If you are trying to implement a binary ASCII protocol that can contain NULL characters inside the string, the Unitroncis PLC will stop transmitting (or receiveing) once it sees the NULL. This can result in only part of the string being transmitted or received. * DLE-doubling and other escape sequences. The 3964-R serial protocol uses the character 0x10 as an escape character. If it appears in the middle of a string it must be repeated to ensure it is not interpereted as an escape sequence. There is no built-in way that I can see to implement this type of feature in the Unitronics Protocol blocks. I think it could be done in ladder, but would not be pretty. I haven't gone over the BAC protocol to see if either of the above issues arise, but that is a summary of my experience so far.

For the record, I was aware that it was "possible", but it's not really what I would consider a robust solution, partcularly when advising another person to do this. Who is that person going to blame if it gets them into a mess?