Nibroc

... they fit now ... something to do with available 'global space' on the forum server. It appears to be low!! I have one more - but I will wait until it will squeeze in ... Tim

Hi Sleepy, Been a wee while since my last post.. I note that the forum is alive and well! I have attached some pics below which may help with configuration: You will need to install Omron Fins Gateway 2003 You will need to download and install the Citect FINS driver (from Citect) Map PLC ethernet unit to network number 1 (using routing table editer via CX-Integrator) Configure Ethernet network in Fins Gateway (see picutre) CX-Programmer can connect via Fins Gateway (see picture) As a side note, CX-Programmer and Citect can connect to CX-Simulator via Fins Gateway, make a great SCADA test platform. (see picture for some clues) Tim ... There is no room to add my attachments ?? I have two files at 200k each ... Tim

Hi Eric (an Scott!) You will need to download the Omron FINS driver from Citect. (not to be confused with OMFINS which wont work!). I suspect you will also need to run Omron FINS Gateway 2003 middleware on the PC. (FYI Eric - Fins Gateway comes with its own .net 1.1 library! (not required for Citect comms) You will need to map the PLC ethernet unit to a network number using the routing table editor. You will also need to configure the FINS gateway ethernet unit. As mentioned by Scott - BobB should be able to help you with Citect connections (I am a few years rusty) Tim

... Sorry, I do not have any experience using winsock - have been using .net TCP Client class - do you supply the PLC IP address and the port number ? You may also wish to confirm that you ETN21 is set up correctly ... Nibroc

... Hi, I think it is possible for citect to communicate to CX-Simulator using the omron FINS protocol. I am not sure if Citect includes the FINS protocol driver as standard (we used to have to install it separately after installing citect - the driver was available from citect, do not confuse the FINS driver with the OMFINS driver!). This all operates in One PC! (no serial comms required) Simply: 1. Start CX-Simulator, create your PLC with units at you intend to use 2. 'Connect' to the PLC in CX-Simulator 3. Start 'CX-Programmer', create an application (set up using your PLC type), set communications to 'Finsgateway', settings are Network 0, Node 10, Unit 0 4. Use CX-Programmer to create your program, you can download/monitor etc the 'PLC' (CX Simulator) EXACTLY like using a real PLC. 5. Configure Citect to communicate with the 'PLC' (CX Simulator) using fins driver, PLC address Network 0, Node 10, Unit 0. Both CX-Programmer and the SCADA can connect to the simulator (PLC) at the same time, you can online edit etc per normal. Note you can save you PLC in CX-Simulator and re-use it though out your development, also note that you must start CX-Simulator before you Start CX-Programmer for this to work correctly ... Note also that you DO NOT use the 'Work Online Simulator' function of CX-Programmer, you simply use the normal 'Work Online', Download etc (CX-Programmer thinks it is a real PLC) I haven't got citect installed on any machines at the moment, so cannot test this, but it should work fine. When you finally want to use a real PLC, simply change the communication settings of CX-Programmer and Citect to suit. I have tested all of the above, and it works fine with CX-Supervisor instead of Citect, can't see any real difference ... Nibroc (Screen shot shows windows from both CX-Simulator and CX-Programmer)

... Hi, To open a TCP connection to the PLC takes several steps: 1. Establish TCP Connection 2. PC sends local (PC) FINS node number to PLC 3. PLC sends the PLC FINS node number to the PC (TCP indicator on ETN unit should light at this point) After this 'handshaking FINS communications can take place, (using node numbers as above) You need to read section 7-4 of manual W421 for a more detailed explanation, including the commands and repsonses required for steps 2 and 3. There are also sequences to implement to handle re-establishing connections which were improperly terminated etc. (although if your application is simple you may not need to bother with these) ( I am currently in the process of writing some C# .net classes to deal with FINS, FINS using UDP, FINS using TCP, FINS using Hostlink, FINS using Toolbus etc so have a little experience with this ...) Nibroc See connection diagram

... oops, no - I did mean milli second, (I should read the post properly ) - thanks sleepy. however I agree this is not fast enough. The fastest setting for a timed interrupt is 100 micro seconds, which is fast enough. (although I would definately do some testing to prove this as a solution - is only a suggestion at this stage) Nibroc

... dont forget to check that the RS232 cables have the RTS/CTS connected ... (you need to with the 802) Nibroc

Hi Sleepy, (haven't been around much lately, although I keep an eye on the forum and note there are many valuable contributers to this great forum ) Was just trying to provide some food for thought: A/D can be set to 250 micro seconds. A/D can have cyclic refresh switched off (PLC settings, SIOU refresh off selected) PLC can have timed interrupt which could execute IORF to A/D unit every 100 micro seconds, and store the value (will get approx 40 samples is 4mS, however a max of 16 different values possible) Although I understand that the PLC reads (refreshes) the A/D only once per scan under normal settings, I though it may be possible to refresh more often ... Just a thought .. Nibroc

Hi Ben, You could make the PLC do an IO Refresh (use the IORF ladder instruction) every 1mS using a timed interrupt ... ?? You can also disable the 'cyclic' refresh of the analog (SIOU) unit in the PLC settings, and then perform a refresh when you wish (eg timed interrupt). The IORF function can be used just to refresh a particular SIOU (analog) unit. Have a look also at the CJ1W-SPU01 data logging unit also. Just some ideas ... Nibroc

Hi Scott, Check that the kinematics converters are suffix 802 models, these are suitable for multidrop. 801's do not support multidrop. On the RS232 side of each kinematics you will need to wire the RS/CS pins as well as SD/RD. I have used them before and they do work. Let me know if this helps ... Nibroc

Hi, ... you can also set the network address for the serial port in the routing table ... I cannot test if this works as I do not have an NS handy at the moment ...

.... Hi Mos, (yes - you cannot use the linear counter and rate measurement feature together) Some other ideas over using a standard timer (some inaccuracies exist with standard timers and PLC scan rates etc) - You could use - 1. Timed Interrupt 2. Free running millisecond timer Another note is if you have a low pulse count per rpm you may get fluctuating results - some averaging may be required ... (or a higher resolution encoder) ... the trick is that any averaging will slow the response of your result!! Nibroc

Using .net 2 with visual studio 2005 I found I needed to turn on 'RtsEnable' to establish any serial comms (this made sense but it took me a while to find the setting) - this was using the serialport component of .net 2.

Frank, Out site consists of 2x CJ1G-CPU43H CPU's, (firmware version 3), each has a CJ1W-ETN21 ethernet unit, and are connected to the Intouch PC. Everything works fine. The Wonderware Intouch is using the Omron FINS driver which was supplied on the Device Integration CD. This driver requires Omron FinsGateway Middleware (supplied by wonderware on the device integration CD) to be installed. Communications Path is: Intouch->FINS Driver->FINS Gateway->PLC I can't remember off hand the setup details, but I will be happy to take notes (screenshots etc) next time I visit the site (next week I expect as I need to install the latest wonderware updates). Configuration did require: 1 installation of Omron FinsGateway Middleware as supplied by Wonderware (I do recomend installing a later version though eg Version 2003) 2 Configuration of FinsGateway (configure ethernet network with your CJ1 node) 3 Install Wonderware Omron FINS driver 4 Configure FINS driver (set up PLCs and addresses etc) 4 Configure Access Name in Intouch 5 Configure Tags in Intouch Not sure why you have been advised that CPU's over V2.24 are not supported. (we are V3's) Nibroc

... There is this page on the japanese FA site for new products (not english though), it is usually updated at the beginning of each month. http://www.fa.omron.co.jp/new/index.html Nibroc

Hello all, Normally I reside in the Omron forum however ... I have an application where I need a PC to communicate to a Control Logix via ethernet. The PC will be programmed using C++. The PC will need to continuosly read several registers (eg array of 10 16bit tags) and occasionally write several registers. Question: Is there any protocol description published to allow us to do this, or do we need some middleware (software or hardware) of some sort? This will be only a one-off application. (it may be cheaper to spend money on middleware to save hours of engineering) I have looked into using a Red Lion DSP (protocol converter) which can act as an Ethernet/IP slave to the Control Logix (control logix will treat it as an ethernet/ip node), and provide modbus/TCP slave functionality for the PC to access via C++. This solution would work, however if there is a protocol description available we will able to build a simpler system. Thanks in advance. Nibroc

Thanks, I will look into using the RS-Linx DDE. - I have looked at the data sheets and it appears the 'single node' version should be fine. We need to poll rapidly, could I expect continuous read response turn around in under say 200mS - 300mS for 10 contiguous items of 16bit data? - Will RS Linx be able to update that data and 'exchange' to our C++ application fast enough ? Nibroc

Scott, Some (random) thoughts, This comment is incorrect, hostlink will work with either RS232 or RS422(or485). Most commercially available 232/422/485 converters will work fine. Omron NZ offer the Omron K3SC, and also an alternate brand product, both of which work fine. What type of SCADA is it - if the SCADA supports FINS protocol (not host link) I would suggest upgrading the CPU21 to a 51, adding a couple of controller link cards which are far superior to any serial link. The FINS protocol allows direct access both PLC's accross the network. (it can route through the connected PLC) Even better - replace the 21 with a CJ1 using a Controller Link card for PLC link, and Ethernet for SCADA link. Do the PLC's need to exchange data ? If not perhaps it would be simpler to have the SCADA connected directly to each PLC using two separate serial lines? If you move the SCADA link to the 51, the SCADA would not be able to directly access the 21 via any seral connection. You would have to rely on the 'data link' to read/write values to the 21, and the SCADA would access them from the 51's memory. Be careful with the NT's (per previous thread), note that an NT11 does not support NT Link 1:N, hence cannot have multiple units connected to one PLC port. Other NT's can. (best to check) There are several ways to connect the PLC's using serial, I would lean towards the built in data link over using protocol macros. (connect RS422 port of SCU on the 51 to the host link port on the 21 - only one RS232/422 converter required). The built in serial data link is faster than protocol macro, and would not require you to engineer any software. Give us a call, it is the season to have a quiet beer ..? Nibroc

.. Transmit 5 bytes for "S,CR,LF" , (if commas are to be transmitted) - be careful to set TXD to transmit bytes in correct order. Nibroc

... better copy of ascii table ... (google search will find one quick too!) nibroc

... What about using the port restart bit. A526.00 This will reset the RS232 port. Nibroc

... Example ladder code attached ... This code performs 'maths' as you describe ... Nibroc ASCii.cxp

... Ladder Code Approach: (Possible with any CJ1 series) 1. use the HEX(162) function to convert the ascii to a hex (BCD) number - the best result would be to extract a double precision (32bit) hex value (8 digit BCD value 2. using either +BL(401) or ++BL(591) functions create the three subsequent bar codes (BCD addition / increment) 3. use the ASCII(086) function to convert the BCD value back to ascii - note that some manipulation of data may be required to shift bytes etc depending on how ascii arrives into PLC memory, some study into operation of HEX/ASC functions will be required. see manual W340 section 3.12 for help with these functions. The Structured Text Function Block Approach (Possible with CX-Programmer V7) CJ1 CPU) as suggested by anonymous may be a good way to go, but will not work with the early V1,V2 (or V3?) CJ1 CPU's. The ladder code approach shouldn't be too difficult for this application. Nibroc

... I don't believe this is possible. You could download your cx-p code into a cpu, and then upload it with syswin (if you have a cpu about - perhaps someone here could do it for you if no cpu handy) Nibroc