Michael Walsh

Thanks for the update!

https://forums.mrplc.com/index.php?/files/file/1162-nx1p2-modbus-rtu-code-and-write-up/

NX1P2 Modbus RTU Code and Write Up. View File This code is designed to implement Modbus RTU on an NX1P2 Controller using the NX1W-CIF11, NX1W-CIF12 or NX-CIF105 module (mounted to controller or EtherCAT coupler).  Created by an Omron Engineer. Submitter Michael Walsh Submitted 05/22/20 Category Tutorials and Quickstarts

Well, that could certainly be done on the Omron side as well.  If the Fanuc needs an integer, we can do as I stated very early in this thread.  However, it seems the Fanuc has no problem sending a real to the Omron controller.  You would think it could handle a real being sent to it.  

Of course you need to be online with the controller and depending upon the memory area, you may need to be in program mode. 

Yes.  3300.00 would be the first bit in that area. Each address is a 16 bit word, so 3300.00 - 3300.15 is the first word, 3301.00 - 3301.15 is the next and so on. 

Ultimately, the data is being sent as a hexadecimal value.  It is all in how it is interpreted.  If you look at what the Fanuc is sending the NX1P2 using Wireshark or something, it is sending a value of C316 0000 (hex).  If you then tell the NX1P2 to interpret that double word of data as a real number (by making the variable that receives it a REAL), then it will use it as -150.0.   Likewise, going the other direction, the NX1P2 is sending out a double word of C316 0000 in hex and the Fanuc needs to interpret that as a real number.  This number could just as easily be interpreted as a signed double integer and would have a value of -1021968384.  This would obviously produce a non-desirable result.  In my opinion, there needs to be something done in the Fanuc controller to make it interpret this data as a REAL number.  

This is odd.  C316 0000 is the proper format (mantissa and exponent) in hex for real -150.0.  It appears as if your robot is simply not interpreting it as a real number.  Is there some setting in the Fanuc to tell it to interpret the variable as a real?  

I assume that your difficulty is with creating the code to do it, not with the actual creation of a function block. So, I am just showing the code below. You can use the Union functionality. First, open up Data Types and create a union: Then create a variable of that union type (MyUnion in this example): Then you can do a move from the byte variable that you want to convert into MyUnion.ByteLevel as shown below in rung 0.  Then you can use the bits within that byte as shown in rung 1 as MyUnion.BitLevel[0].  

DWORD values do not have a decimal portion.  Real numbers are the way that you can express this type of number.....  You could multiply it first as a REAL and then convert. so,  100.342 x 1000 = 100342.0  Then convert: 100342 would be the DINT version and if you do DWORD (DWORD is a somewhat generic format displayed as a hex number), its value would be:  187F6. I am not really sure why you would want to do this though.  What is it you are trying to do?

This is not what he is asking for.  He is asking if there is a way to save I/O patterns so that his program can be tested in simulation mode with somewhat realistic interaction with the I/O.   I think what you are looking for is I/O Conditions (and the replay menu).  You may have to manually create a file, but it looks like it does what you want.  Look in the CX-Simulator manual that is installed with CX-Simulator in the start menu.  Check out section 3-9-5.  

I believe that Sysmac Studio can update the version on the NA5 quite easily and it does not take long.  

@Abdul Wajid Done.  

@chelton I found out that Sysmac Studio uses DirectX11 and VMWare does not yet support DirectX11.  

Look at the NX_SerialStatusRead Function block.

Here is a document that details updating the clock on the NB from the NJ/NX controller.  I know this is not exactly what you want, but it should be the same from the HMI side: http://forums.mrplc.com/index.php?/files/file/1161-setting-the-nb-clock-based-on-the-nj-nx-clock/

Setting the NB Clock based on the NJ NX Clock View File This document details the updating of the clock on the NB based on the clock in a Sysmac Controller. Submitter Michael Walsh Submitted 05/14/20 Category Tutorials and Quickstarts

Here is a thread on updating the NS, you should be familiar with this one @BobB: http://forums.mrplc.com/index.php?/topic/23351-automatic-update-ns-screen-timedate-from-plc/#comment-112758

No, you are thinking about it the right way, not misunderstanding.  I will look and see if I can dig that up.  You are right, there seems to be limited info on this.  

Are you referring to using the CIF12 for no protocol mode?  If so, look at the NX_SerialRCV instruction.  It has the size and the buffer data as variables (either in/out or out).

@LD_M:  I pm'd you a link.  

I have never heard or seen anyone using CC-Link with an Omron PLC.  I know that Omron does not make a specific device for this.  I would try to get EtherNet/IP if possible. 

Expand the options under Detailed settings and match up the settings the controller is expecting to see with the settings in the drive.  You need to do this when adding third party devices.  it is usually pretty easy to figure out which objects need to be matched together. Here is an example with a Parker drive: This is the state you are in (I showed the expanded detailed settings) As you can see, the ones that are no good are highlighted with RED exclamation points. This is the corrected setup: As you can see, the choices are pretty obvious.