lostcontrol

Interesting results. I have Win7 x64, running VMWare Workstation with XP-SP3, as well as the windoze Virtual PC. When running the VMWare machine, all PLC types are recognised by the VM, & can be connected to ( disconnected from the host ). The NS is also recognised & can be connected to. When I try to go online to a CP1L/H PLC, the connection times out & brings up the standard message of: Now I thought I would check with an NS8, to try & prove USB connections/cables etc. I could connect to the NS & upload/download via USB. I also today had access to a CJ2-CPU33. I could connect to this PLC & upload/download etc all with USB. This then leads me to think that there is something odd with the way that the communications are done to the CP1L/H range. I recall when we first went to VM's, that the VM would crash if connected with USB, then disconnected & reconnected again, unless the physical USB connection was disconnected/reconnected etc. This would not happen with a CJ2 though. I have this case raised with VMWare, but they have pretty much drawn a blank on it. They managed to prevent the crashing of the VM, but to reconnect to the PLC successfully, the physical connection has to be re-done. I used to be able to connect to the CP1L/H PLC's from the VM on this host, but now I cannot. It could be due to any no of windoze updates also I guess. I would of thought though, that the USB connection method for the CP1L/H & CJ2 PLC's was similar, but it appears not. Does anyone have any similar experiences with this, suggestions on what to do to fix? In the meantime, I have to carry a 2nd machine with a XP host to service the CP1L/H range.

Sounds like baldor/ABB drive upgrade? As IO_Rack has said, what modules are on the PLC rack.? you shouldn’t need to access the PLC if just doing a drive upgrade, as long as you can get the config/setup from the current flex drive. From there, it should be just autotune & go.  

This sounds like a bug in sysmac somewhere, as I recently had something similar. Opening a project that was all ok & had the EIP mappings are broke. I need to check if this was from an import or version upgrade tho.

Can the 'mode of operation' be exposed via the PDO mapping? 

Is this a working system or new.? ive had an L16 embedded IO go bad before, fortunately not much was used so could easily move to the expansion modules. 

This is where I would be focusing. Depending on the size of the servo, I would expect it to react back (as you would ) Do you have the manual that breaks down the control word? Perhaps that a single bit that is not being set correctly via the MC instructions? I am thinking that you should be able to do everything without the SYSMAC motion instructions to confirm the PLC-Drive functionality & that there is something missing in the actual motions maybe. (you will probably have to un-allocated the control word though.?) This is just an assumption though, but maybe something I would be trying if it were me.

No. You need to do the following: MOVR 100.0 IR0 MOV D0 DR0   XIC DR0,IR0 to use the bit in the offset (apologies for the AB reference :( )   Also, your code below the indirect function will undo what you are trying to do anyway.        

Use CJ1. All that does is assist in the available IO memory (or similar) & where things are stored. as an FYI, DASOMFINSEnet has been replaced by OMRONFINS, which is a shame as DASOMFINSEnet was a far superior version.! DASOMFINSEnet will still run though, but I’ve run into OS issues with later versions of windoze.

so it does, wonder how that works considering sysmac doesn't have the same windoze file access? Maybe it launches sysmac itself?

That probably wouldn’t work easily with SYSMAC ?

My comment was Rockwell to Danfoss FC302, not Omron to Rockwell PF525..   Are you trying to connect a Rockwell PF525 to an Omron Sysmac controller?  

Old thread alert...   But, Only port #2 supports FINS...  However, Port #1 supports OPC-UA which can work with Indusoft/Aveva Edge      

Is your requirement to keep the connection open & continuously send/receive? I suspect this code here is your problem. 42: RecArray2 := RcvSocketDat; Stage :=INT#43; Stage == 43 is close socket.  If your intent is to send/receive continuously, then there is no need to close the socket once the data is received.   Without doing all the leg work for you, I would consider the following: 1.Moving Stages 40-41-42 to be always running if 'DoTCP' is True & socket.IsConnected 2. Either alternating 500-510 or running them both at the same time, depending on the server requirements. (applications I have done worked this way..)  

Have you created that 'DoTCP' function block yourself, or got it from somewhere? I haven't gone through it completely yet, but why is it wrapped up in a FB? Is there multiple instances, or just done for re-useability?

you will need to post what you have done so far, so that it can be viewed & commented on.

I am sure you would of checked, but is there anything writing/resetting the system clock using the 'SetTime' instruction?

Union is the way to go.! whilst it an extra step/tag perhaps, it does give a lot of options

I have done both, simple change on the block type only 

The intent of TCP is to keep the connection open, so you should not need to close it unless there is an error with the connection. What do you mean 'dusty' ? Is that the command you have sent? Are you sending the correct data, including start/end/byte count?  

that was it!!!!    

Hello, Anyone know of a way to reset a NX102 ethernet port programatically, using CIP commands perhaps? There is a button within Sysmac that does what I need, but want to implement that via code.      

YES!! Doh, the reason I did not try this as port #1 on this NX was dodgy from memory 

ahh, so I just copied the same code to a NJ101 that I have & get the desired result. (kicked off) I have a counter on '_EIP_EtnOnlineSta', that is incrementing each reset. The only difference from the NX102 is the path NX102: '01#01\02\192.168.251.1' NJ101: '02\192.168.17.179'

to  port #1? Have you tried port #2?