innoaloe

The MAX485 mentioned in the manual is for MX-106R series which indeed supports RS485 (has 4 pin connectors). In your case with MX-106T, the Motor side uses UART, so the easiest way to get it converted on the PLC side is by using MAX232 chip instead. It will convert the UART protocol into RS232. There are plenty of circuit example available online for that chip. Regarding the single pin for both TX and RX on the motor, you can solve the issue pretty easiliy by using a Schottky Diode. Get one with a low forward-bias voltage (0.3 V or less), and use it in a configuration like in the picture below. The diode will ensure that signal goes one way from the MAX232 TX Output into the motors DATA input. When a DATA is sent from the motor, it will only enter the RX Input of the MAX232 since the diode is blocking the TX side.

Use the GMAN trick. It helps

Good to know that it solved the issue :)

I think I'm starting to get what's happening... but you need to try it. Delete all of the Initial Values set for your Socket variable. In the SktUDPCreate documentation it describes that both SrcAdr and DstAdr sections will be filled with zero once the socket is created. As UDP is an unconnected communication, you don't need to specify any source IP Address. If the UDPCreate is successful, fill the DstAdr with your target device IPAddress and PortNumber, then try the UDPSend command. The Handle value is basically just a pointer. If you Create a socket one time in the entire program, it will be filled with 1. If you create another socket, it will have 2 as the handle value. If say socket 1 is closed properly, next time you open a socket it will get 1 as the handle value. So it's predetermined by the CPU.

To save / import in / from SDCard, just use "\SDCard\RecipeName.csv" as the FileName To save / import in / from in USB,  just use "\USB\RecipeName.csv" as the FileName

Port Number does not matter AFAIK, as long as it's not the common port number used in other TCP/UDP protocol (like port 80) or not being used by another Socket. I see in your variable tables that you are Initializing some values, such as the Socket definition. I think, prevent to Initialize the "Handle" value of the Socket. When you are Creating a Socket by the Create FB, you will get a new value assign to that Handle, just as a pointer. This is later on Outputted by the Create FB. Try checking the current value of the Handle in your Socket. It will not be able to send anything if the value is 0.

You cannot put the internal memory location (like %W0.00) in the ladder directly. You need to create an Internal Variable in the program and put the %W0.00 inside the AT column of that variable in the variable table. If your PLC Type is the NX1P2 series, you may need to edit the Memory Settings in order for % symbol to be applicable in the AT column.

Check whether your program is in between Interlock (IL and ILC) instructions. Other case, you may have created that part as a separated program (not section), and forget to set its properties as a Cyclic Task.

This one saved me... wonder why this is happening in my new PC, while I installed the same version on another PC with the same Windows 10 without issue.

I don't think itcs possible to get independent R G and B values unless you dynamically change the light source to either R G or B as set in the index 202. This in turn will increase cycle time. For such detailed inspection, Vision inspection is your best bet. Photoelectric based sensors just won't do it.

Again... what version is your PRM21? And does your CX-Configurator contains a DTM Version for that model or not? Seeing the scan returns error with DTM version 1.0, I think your CX-Configurator is an outdated version. Try to run the AutoUpdate so you'll get a newer version (if you have a registered copy)

Not an AB guy... but there is no direct conversion for this kind of issue. You are swapping a protocol to another here. The document you provided there is like a comparison table of Sercos vs Ethernet/IP. I don't know whether AB have Function Blocks for the EIP drives or not, but I believe they have for the Sercos one. You cannot reuse these Sercos FBs obviously, and need to reprogram the PLC using the way EIP way.

In your post you mentioned that you want to get the current value that the sensor sees. This means instead of reading index 202, you should read the Cyclic Process Data, which will be mapped directly on the NX-IO Link master variable. You can find this easily by looking on the IO-Map table and see which has a varying value based on the current color that the sensor sees. I've had a look on the Keyence's manual, and it says Index 202 is a parameter to either Get or Set the light source used for the sensor. It's not to get the current RGB value. Basically if you Read this Index, you will just get a value ranging from 0 to 4 which describes what light source is currently in use. Alternatively you can Write to this Index (using IOL_WriteObj FB) to Set a light source that you want. That being said, if you really want to Read index 202, you should put USINT#202 on the DeviceObject.Index variable. Since this parameter does not implement SubIndex, keeping the DeviceObject.Subindex variable to zero is correct. In your setup, I consider you wire the sensor to Port1 of the IO-Link master, and the NX-ECC Coupler is set to NodeAddress 1. What you are missing is the DevicePort.NxUnit variable. Fill this with a structure of type _sNXUNIT_ID. You can generate this variable automatically by going to the IO-Map section and right-clicking on the NX-ILM, then clik "Display Node Location port", then Map the variable.

Good to know you have solved the problem. And regarding Scanner, I don't think you need to since in this case the NX1P is the Scanner, so your DX200 must be set as the Adapter. It's a good thing if you can share a guide to solve this issue. Maybe someone will be in need of it, although no one's is pushing you to do so. Feel free if you feel like it. At minimum maybe you can tell what's the main cause of the problem you've faced before :)

This is one of the feature that will be typically overlooked... Never set this one before. Nice find @b.k.n.. Though I think the longer we set this of course PLC cycle-time overall will be increased by this value.

There is the I/O Configuration tab on the bottom of the screenshot you sent, which I rarely seen in EDS Parameter. Try checking out what's inside that

It's basically the EDS file itself, in a human readable form. The naming conventions can be confusing since different vendor uses different naming sometimes. In this case, in the DX200 we have OUTPUT Instance 102 and INPUT Instance 101. My guess it means 102 are the memory instance to be sent to PLC and the 101 is the memory instance that need to read from PLC. In the NX1P side, Omron naming convention is always seen from the PLC side as the Scanner / Master unit. So the meaning of the INPUT Instance in Sysmac Studio actually refers to the memory instance on the DX200 that sends data to NX1P (Output in DX200 :)). That's why it is 102. The same applies for the OUTPUT Instance which is 101.

You don't need to rename them, but you need to register the memory as a Network Variable. This can be done in CX-Programmer Symbol Table. For example you register the word area D0 as a symbol "Counter" with type of Network Variable selected. This Network Variable table can exported from CX-Programmer and then Imported to Sysmac Studio NA-HMI editor.

Depending on your CJ1W-PRM21 version (latest is 3.0 I think) you might need to upgrade your CX-ConfiguratorFDT in order to make it work. CX-Server is a middleware that is installed along with other software during CX-One installation.

@00MM is a HostLink command, to read the PLC Model (with the 40 at the end is a CRC code) @00MS is also a HostLink command, which is used to read the current status of the PLC (whether it's in Stop/Program, Monitor, or Run Mode). None of these are a prerequisite to enable communications between the HMI and PLC. The PLC is basically passive, waiting for any request from the connected device, and it will respond accordingly. So that's not the issue here. Maybe you can attach your cable pinout configs, and also communication settings you've done on both the NT30 and the Proface

Man... I may need to start on thinking how machines sees the world again :D Nice input there Crossbow

I don't think the issue is with In/Out being reversed. How about the External IO Allocation page in the DX200? I believe it should be set up prior to generating the EDS otherwise NX1P2 will not know to which physical memory the 128 bits is to be read/write.

Welcome! You can use the Divide instruction to get around your problem easily. If you look into the Divide ("/") instruction manual, you will see that the output of that instruction are both the quotient and the remainder of the division operation. For example if you Divide 10 with 2, you will get 5 as the quotient and 0 as the remainder. If you Divide 11 with 2, you will get 5 as the quotient and 1 as the remainder. To check whether a number is Odd or Even, you just need to divide it by 2. If the Remainder is not zero, you can be certain that the number is Odd. Something like the example below should do the job, I think...

As you said you are using Star Network, then topology should not be a problem. Then I guess it comes down to the fact that we are using FINS/UDP. As it uses UDP, all packets will be broadcasted to literally all connected devices. Although the device that is not the target will reject the transmission, it still takes a lot of bandwidth. In my opinion you can still save the NA from lagging by using CIP communication instead of FINS, because the CIP method uses TCP connection that ensures each NA only talks to the PLC and not broadcasting the packet elsewhere.

Are you running those NBs over Daisy-chain network or a Star network? Daisy-chaining will most of the time cause lags the more additional Network Switches you add