Nibroc

Hi Bob, PMCR, Just been in Germany for three weeks - went to the Hanover Messe - didn't see Omron or AB! But still plenty of exhibits. I hope they update the documentation for CX-Gateway, perhaps create new 'Operation Manual', 'User Manual' and even a manual for the .net functionality. There used to be a Website for FINS Gateway, which is still operating but way out of date - perhaps update / remove / redirect this? Found the link the other day but can't spot it right now. Tim

Hi Bob, Hope all is well in Sydney!. Yes, I downloaded the document from here which described FGW2003 compatibility with Vista, so I had no immediate concerns. It looks as though Omron have brought the product fully up to date with CX-Gateway. Nibroc

Hi Guys, Everything and more (CJ2 + USB supported), CIP also ... Thanks for the update and link. This confirms viability for some concepts I am scheming up ... I felt Fins-Gateway was gathering a little dust ... Nibroc

... Had a quick look through the manals and I cannot see any particular tricks or traps. There is one comment which suggests that CX-Programmer displays the average of the last 8 cycle times, however you should see the raw value in A264-A265 (double) as you suggest. Any chance your program periodically performs any FOR-NEXT loops, large data transfers, large word shifts, large bit shifts? Nibroc

Hi Simone, I'll have a look through the manuals tonight, I have never looked closely at CPU timing settings. One idea - off the cuff - would be to run your whole program in a scheduled task ? Nibroc

Hi Simone, When monitoring the PLC with CX-programmer and performing other operations such as on-line edit, the PLC cycle time may increase as the PLC CPU must process communications and other commands sent from CX-programmer. The communications load caused by CX-programmer will vary depending on what variables are displayed on-screen, on-line edit operations, memory watching etc. Have you set the Watch Cycle Time ? - normally I leave this at the default 1000ms. I have never used a fixed cycle time, I leave it as default being as fast as the PLC can go - do you need to do this ? Nibroc

Just a note: I had a colleage with an issue downloading programs to a CJ1-CPU-'R' series PLC via ethernet UDP. When a program was downloaded via Ethernet UDP the program would become corrupt and the CPU would report a fatal program error. The issue appeared to be that function block definitions were not being transerred during the download. Both Serial and Ethernet TCP downloads are fine. This problem was experienced after CX-P7.2 was updated to CX-P7.3 via an internet update. I am not sure which version of CX-Server was installed. This is just a note to warn people if they strike this problem - use serial or Ethernet TCP as a work around. Hardware was an 'R' series CJ1, with an ETN21 unit. Ordered our copy of CX-One V3 today, I wonder when we will get some CJ2's - and then I wonder how long it will take the various third party SCADA/HMI vendors to update their comms drivers to match ... Tim

... Hi Bob, We have used UHF radios with RS232 installed over much larger distances than 5km. (40km on one link). Proper selection and engineering of the radio link is important, you would need to consult an expert. Choosing the correct frequency etc for the topography(each radio path) can make quite a difference - we use licensed bands as there is much less chance of any outside interference. I note that some of our remote sites are down a gully, and are certainly not line of site, however we do acheive reliable communication. Over here we are currently using Tait radios, however, I think Trio(among others) may be worth a look in Aus. Note that I am not involved with engineering of the radio links, we use a sub-contractor for that aspect. I suspect you have already given due considration and ruled out direct point to point radio links ... Nibroc

Just a tip: If a function does not appear to be working (such as PID), check the status of the error / carry flags to confirm if the function is operating or in error state. Nibroc

... Great, CJ2 looks like a good step - funny though, down here in NZ we are still being supplied with the odd V3 CJ1!. DM and EM bit adressing will make life easy. Ethernet I/P will be good too - I recently commissioned a CJ1 system using the EIP21 unit. It worked great with Beckhoff I/O and Altivar VSD's distributed on Ethernet I/P. When will Omron release the Smart-Slice with Ethernet I/P ?? and what about some VSD's ... ?? Hope the CP1 series is upgraded with all the latest features ... at this stage they are only the equivalent of a V3 CJ1, which means we can't run our V4 function blocks on a CP Nibroc

Another note, Wonderware now offer a FINS DAS (data aquisition server), which may allow you to drop the Kepware middleware and communicate direct to the PLC? Nibroc

Hi Todds. The Kepware FINS address should be 5.95.0 (network 5, node 95, unit 0). This addresses the communications to the PLC's CPU unit, which is always 0. Unit 2 is actually the ETN21 itself. Not sure if this is all of your trouble. Nibroc

Hi Scott, You can use the dr,ir method for dynamic addressing of bits (or words) from within your ladder program. (you probably already know this?). For example: LD P_On MOVR(560) 0.00 IR0 LD P_On MOV(021) &10 DR0 MOV(021) &12 DR1 LD DR0,IR0 OUT DR1,IR0 ie, when CIO 0.10 is on, output CIO 0.12 is turned on. The indirect adressing can be very powerful. The dr is the pointer and can be easily manipulated. Not sure if you are already familiar with dr,ir ? Tim

Hi Scott, Yes I too, am aware of V2 and have seen some detail of the new specs/improvements. Been a while, very busy here, how about you? Tim

... Yes I too have reached the limit on a project I am doing. This was looking to cause me a major problem. I got around it by removing all the comments attached to be alias'. Thus reducing the total number of characters in my alias table, and now sufficient for my project (approx 1000ish alias definitions). This potentially could have caused me some major problems. I am using V1.22 (old but no updates have been made available to me down here in NZ) Nibroc

... What model of PLC are you using - are they CJ1Ms ? If so, have you looked at using the built in serial data link function. Do you have the manuals you need ? The TXD function can also send hostlink data, have a look at this instruction in the manual. The TXD / RXD functions can be used to send protocol free data with the PLC ports set in 'RS232' mode. It may be easier to implement this method. (unless you need error checking). SEND / RECV should work, however I don't have a test rig ... Nibroc

Hi, Firstly - if your PLC's are CJ1M series (not CJ1) you should look at using the built-in serial link. If not: I haven't personnally used SEND, RECV via serial (but have via controller link, ethernet etc). The 'FA' denotes that the message is FINS protocol, (encapsulated within hostlink). See Omron manual W342 for help with the internals of FINS protocol, and C - Mode (which is hostlink / sysmac way) The port set to RS232 (non protocol) will not respond automatically to a hostlink/fins data packet. The port should be set to hostlink, toolbus or possibly serial gateway. The serial ports are mapped to a network using the routing table tool - they may be set to a network number by default? Both Master and Slave PLC's should have ports set to the same config. I would configure one PLC to behave as the 'Master', and use both SEND and RECV commands from this end only - otherwise you will have collisions which the serial cannot deal with. The 'slave' PLC should respond automatically with no special programming. I suggest using the Omron function blocks CPU010 (Send data), and CPU011 (Receive Data) instead of the ladder equivalents. They are much easier to use and save much time (although they do use the ladder functions internally you do not need to worry about them). These are some pointers only - I have not actually used send/receive over serial and do not time to set up a test rig - it will work ... Tim Corbin

We are in the Omron forum. I was trying to commission an Omron system, as such, I must comply with Omron requirements Nibroc

I have deleted my original response to the above and now decline to comment any further. I do not wish to argue as to whether EDS files are or are not necessary. This was not the purpose of starting this thread. Nibroc

Download EZ-EDS from ODVA, make an EDS to suit your device. There is even an EDS Authenticator tool. Without this, unfortunately you will not be able to integrate your products with the Omron scanner. Nibroc

Update: We now have CJ1W-EIP21 to ALTIVAR 71 VSD communications Schneider sent us a new EDS file all the way from France, and away it went !! I won't go into details, but as we computer people know, it only takes one little setting to make a big change !! If anyone needs the correct EDS in the short-term, PM me and I will email it (also for ALTIVAR 61). Medium term, Schneider will provide an updated EDS. P.S. - Finally we have datalinks using ethernet (EIP21 - EIP21) and to other brands as well ... Nibroc

Hi Peter, Yes, the Omron Configurator does require EDS files. It appears that they are used by the configurator provide a relevant 'GUI" for each device, allowing selection of various parameters such assembly instance and i/o sizes. Yes, I note also that the Manual for the Altivar VSD gives an example of integrating the VSD into a control-logix system by setting it up as a 'generic ethernet module', then just type in the assembly number, and sizes and away you go ... However, we do not have a 'generic ethernet module' supplied with the Omron Configurator, and I suspect that your product utilises the 'generic ethernet module' / EDS as suggested above. Nibroc

Update: I have had the Schneider Tech guy in my office for a couple of hours with no luck. He is now up to speed with my problem. - The EDS file was definately incorrect, and my modifications were justified. He is going to request advice from 'above'. However, I have now spent many hours on this problem and am unable to establish 'proper' communication between the Altivar and EIP21. Although we are able to establish a valid connection (both EIP21 master and Altivar are happy) and have tried all the various 'asseblies' offered we are unable to control the Altivar. (Note that I have used the Altivar before with Devicenet to Omron, and also with Modbus TCP - which will be my fallback position if not resolved soon!) We would like to implement the assembly 100-101, which simply reads / writes 16 bytes in each direction. Although we are happily receiving 16 bytes from the drive (all working OK), we are not able to send any data to the drive. Does anyone have any in depth knowledge of the Omron configurator software , and/or the EIP21 ?? Nibroc

Hi Gamerayers, Do you have the omron manual W342 - which describes the Fins protocol ? A great help would be to download the 'Multiway' software available from this site. It is a communications terminal program which supports FINS over TCP and serial. (You will probably be using FINS - Hostlink which depicts 'FINS encapsulated in hostling' - this is an ascii protocol) Your Error Code: @ - hostlink header 00 - node 'zero' FA - fins protocol 'header' 13 - end code (13 means FCS error) - see section 4-2 in manual W342 for end code table (00 is good) *CR - hostlink terminator You will need to write an 'FCS' calculator in C if you wish to to send data to the PLC, as the FCS is required. Each time you write the 42 words, the FCS should be calculated on the send data. An example for this is given in section 2-3 of manual W342. - if you have difficulty here, I may be able to dig up some alternate source code. You can probably use a static 'request' for the read 18 words starting from dm4000 - this would be: @00FA0800003000000000000010101820FA000001273*<CR> Response would be: (would vary if data changes) @00FA00C00002000000000000010101000000000000000000000000000000000000000000000000000000000000000000000000000037*<CR> The relevant sections of Omron manual W342 is section 3, also make sure you look at section 3-5 which describes how Fins commands are encapsulated within hostlink. I hope this helps to point you in the right direction. Note: For your application (read 18 words, write 42 words), the 'C-Mode' (otherwise know as host link or sysmac way!) would be OK, and may be easier to understand. Note that C-Mode does have limitations and cannot access all data areas/commands of newer PLC's. Kind Regards Nibroc

Hi Scott, Yes I have used both Wago and Beckhoff IO recently - it works great. (has all the different network options too!) This project uses 7 Beckhoff ethernet IP couplers with digital, analog and temperature inputs on each. I have the Beckhoff IO working on the EIP21 now. (had to adapt the EDS file to suit each of the 7 units IO sizes and install 7 EDS files with different unit descriptions) However, the ATV71 is not working yet. (yes I have also had 'issues' making the altivar work with devicenet but succeeded eventually) I have concluded now the the EDS file for the ATV71 will also need to be modified to work. For example, by modifying the EDS I can make the ATV71 / EIP21 communicate with no errors, however if I disconnect the ethernet cable the ATV71 does not detect a comms fault ! Also whilst I am receiving data from the ATV Scanner, I am not able to send data! The EDS file for the ATV71 was created with EZ-EDS from ODVA, however some of the instances (eg the 100-101 instance) simply do not work as they have completly the wrong input / output sizes! The trick is, using ODVA products are supposed to be relatively easy - in my experience with devicenet and now ethernet IP, mixing brands with ODVA is not easy. (and becoming an expert at EDS / CIP should not be necessary!) I also wonder (actually strongly suspect) that some configurators 'ignore' certain EDS parameters and simply write their own values in appropriate place (parameters such as RPI, input size, output size). I suspect that this may be a reason why EDS files work with some vendors, and not others?? Any coments welcome. Nibroc