innoaloe

I'm not sure with that though... I still don't think it's necessary to MOV data from D104 to 102. It does nothing aside from changing the settings you have already made on the P_FirstCycle call. Just to be sure, you don't wire the IIN terminal, right? You shouldn't since it's a voltage input. Could you give example on the difference of value? Like if the LCD shows 3000, what does it shows in CX-P?

Custom Keypad usage might one of the worst documented feature in NA. Assuming you know about Custom Keypad already, let's say you have a DateTimeKeypad under Group0 and named DateTimeKeypad0 Then I'd suggest you not to use DataEdit, but instead use the DateTime Standard Control. I don't see the point of using DataEdit when the said control cannot even view Date or Time variables properly. Now that you have your DateTime control in the Page, assign your Date or Time variable to it as you needed. Lets say the variable name is "MyDate" Next, add a Press Event to your DateTime control, and assing a CallSubRoutine Action to it. For example we call the subroutine "CallMyKeypad" Then you create the CallMyKeypad subroutine inside your page, or Global Subroutine if that's necessary. The subroutine should look like something like below. The green parts are just script comment and not necessary. Sub CallMyKeypad()       'You'll see a lot of commas here. Basically some parameter on the EditVariable function are not necessary to open the said keypad       'Important parts are the said Date/Time variable name (MyDate), the Type of the Keypad (DATETIMEKEYPAD)       'and the Name of the Custom Keypad Group that you want to use (Group0)       'We do not specify the keypad name explicitly, since one Custom Keypad group can only contain one definition of a Keypad Type       EditVariable("MyDate", , , , , , , "DATETIMEKEYPAD", , "Group0") End Sub You can find more about the EditVariable script in the Instruction Manual from the Help menu when your Sysmac is opening an NA Project.

CP1L-EM or EL can communicate to 3 TCP servers at max simultaneously. In practice, should you need to communicate to more servers, you can Open-Close the TCP connection, changing target IP each time.

Then you need to measure the rate of change of the said encoder reading. Put a constant timer which run every 100 ms for example. Or better, create a secondary Periodic Task that run for every 100 ms just to read this analog value periodically (from the Task Settings menu) On each cycle, read the analog value of the said encoder. Subtract with its previous reading. Divide the remainder with 100 ms. The result might get jumpy though. You can reduce the jumps by doing an moving-average of subsequent subtraction results (you can find that algorithm in the internet easily) Now for the question whether the result displayed stands correct, that'll depends. Your encoder rated on 0 - 10 V, but for what distance? Let's say 0 - 10 V equals 0 - 1000 mm, which means you'll have a precision of 1000 mm / 10 V = 100 mm/V If your analog input card rate at 4000 for its resolution, the smallest voltage you can measure is 10 V /4000 = 2.5 mV So that means the smallest unit of distance you can measure is (100 mm / V) x (2.5 mV) = 0.25 mm Divide that by 100 ms sampling time, then the smallest change of speed that you can measure is (0.25 mm) / (100 ms) = 2.5 mm/s That's the concept I can offer. Happy coding

Exactly. One NB-Designer project can only have one HMI definition. If you want to have another screen, copy the entire project folder of your current project and rename it. Open the new NBP project file and change the communication settings to suit your needs (e.g. the IP Address of the second NB project should be different from the first project). There is no other workaround aside from having multiple NB project at the moment.

On it's very core, NJ is still a PLC, so unfortunately such dynamic memory management function is not implemented. IMO if you just have 3 Cam tables, it is way easier to create 3 MC_CamIn instructions and one MC_CamOut. Ensuring the Cam transition is easier by having multiple FBs. In the end if you want to only have one FB, you need to make each Cam Table to be in the same master-slave scale, so the array size of those 3 will be the same.

It's not possible AFAIK. Library is the only way to go. The current version also supports GIT already, but it's not a cheap solution :D

Yes, but the same requirement about minimum CPU firmware version applies.

This might be old... but I'm trying to do as what @Nibroc said. However when I'm pressing the "Connect" button to activate EtnUnit for example, the Network Address text stays at 0 and it is grayed out. So no chance to change it. This in turn (I think) makes me unable to find the said Simulator through FinsGateway, since FinsGateway can only find devices with Network Number from 1 and above. Anyone have an idea about this?

Before you update anything, try checking the firmware version of your NJ / NX CPU. Some function blocks only work for firmware version 1.10 or above, so even though you have Sysmac 1.15, it won't be shown since the CPU firmware version does not support it. You can try upgrading the firmware of the CPU, although "legally", only Omron engineer can do that for you... EDIT : As mentioned before, you need CPU Firmware v1.11 or higher to use this instruction. This image taken from the Software User Manual

Batteries will still be needed if you want the PLC clock to keep on synchronized though... otherwise when main power is powered off, the clock data in the A Register can go awry... @Abdul Wajid Yep, leaving by this year from the main company but still got to play with Omron here and there. Who knows though, maybe back in there in a few years. Hhh...

@Abdul Wajid Hi again! Got the business moving now? You've got the answer from the boss up above. If I may add though, you can also use MOVD instruction to take hour digits from A352, put it in MSBs of D1000 for example, then use another MOVD to take minute digits from A351, put it in LSB of D1000. So D1000 will contain "HHMM" values which later you can compare with another Word.

All Array index accessor in the NA usese parentheses since it's based on Visual Basic script. I really hope they used C# for a better script consistency with PLCs ST Language, but I guess VB is easier for most users :(

If so, the problem might lie with the Subnet Mask. Sometimes I find an eMB-60 using subnet mask of 255.255.255.0 eventhough the IP started with 172.xxx Try changing your PC subnet mask to 255.255.255.0 instead. Cannot guarantee anything though...

Well, ping command is just sending ICMP packets so no TCP Connection is generated. That's why it will always work as long as the IP is there. Have you tried using another computer to test the connection?   Try the IP Setup in ACE. There's should be a Magnifying Glass icon near the Connect To Controller option which will shows all connected controllers as long as the cable is connected. From there you can modify the controller IP and Subnet Mask too.

Since you're having Sysmac I believe you're familiar with a tool called DirectEthernetUtility which comes with Sysmac installation. If not you can find the said program in C:\Program Files (x86)\OMRON\Communications Middleware\DirectEthernetUtility.exe This is a very handy tool from Omron which lets you connect to any Omron PLC through Ethernet without knowing it's IP Address (if connected directly with cable). However it causes a royal pain if you're trying to connect to other ethernet devices through your LAN Card (such as Adept robots) because this application generates a secondary Local IP Address starting with 169.xxx.xxx.xxx. All other applications using Ethernet might be affected as well. Two suggestion from me: 1. Keep the DirectEthernetUtility as it is right now, and change Adept Robot IP Address to match the current 169.xxx.xxx.xxx IP and Subnet Mask using C:\Program Files (x86)\OMRON\Sysmac Studio\AdeptRobotIPAddressSettingTool, or better you can change it from ACE (yes, you can change it even without having a correct IP Subnet in your PC). 2. Open the DirectEthernetUtility, disable it, then set your PC LAN IP and Subnet to match Adept's current 172.xxx.xxx.xxx.

1. You're using "F" on channel 1. It should be "E" for 1-5 V input. 2. Remove the MOV D104 to 102. It clears your settings in 102. 3. Make sure you wire the signal to VIN1 and COM1 terminal  

I'm not sure about the terminal block you're using though. It is never listed for R7D-AP model AFAIK. Seeing the example that you've followed, you're doing an Absolute Movement. Did you execute a Homing operation before that? Because you can only do Absolute Movement if servo's home / zero position is defined. There is another separate section in the manual containing example about Homing. I'd suggest you to try the Relative Movement first (Change the 2000.03 bit to the Relative Movement one). You don't need Homing for Relative movement, just be careful since the calculation is different (Absolute = target position, Relative = increment position). If the servo managed to move using Relative movement, then you can be sure that wiring is correct. So you can continue to check about the Homing operation before trying Absolute Movement.

CX-Drive has definition for that servo (It's and old model also). That model was supposedly only to be sold in China region, so you need to adjust your CX-Drive to look on China region database. Go to menu Tools-->Option-->Drive Regional Defaults : Change to China, and you should be good to go.

No... but you can emulate it using internal memory. CMIIW IF Input = TRUE THEN      IF EdgeDetect = FALSE THEN           'Do "Something", anything you want do be done with the program           EdgeDetect := TRUE;     'This will ensure the "Something" will be called only once      END_IF; ELSE      EdgeDetect := FALSE;     'This will resets the edge detection END_IF;

I typically use a pair of AWG18 cable especially for long distance communication (more than 150 meters). For short distance, a STP cable will suffice. It came already in a twisted-pair, so signal crosstalk issue already reduced.

No... And in most cases it's very hard to interface old PLC to OPC UA. You will need to implement some hardware-in-the-middle to do it, which is sometimes another PLC also. Depending on the machine, sometimes it is easier and more cost effective by replacing the existing PLC with a newer generation which is connectable with OPC UA.

Unit number duplication means you have another card (which maybe different than MC402) that uses same Unit Number as your MC402. In this case check whether other card is set to Unit No 0 as well. Sometimes a card may take 2 unit no. space. I don't remember how much MC402 takes, but maybe it uses 2, so you cannot have other cards set to Unit No 0 and 1. Check your IO Table in CX-Programmer first to confirm the unit addressing. If everything okay then you can move on to Motion Perfect

The problem is RS485 signals are typically containing some sort of ID which will tell the slave device who is the target of the current communication. IIRC your MX-106T does not have any settable identifier, so you cannot use conversion from RS-485 protocol to UART. If you want to save number of RS232 port, then you should go with PanicMode's suggestion. Have the PLC talk to the Microcontroller via RS232-to-UART interface, then emulate some digital I/O pins for each motors TX/RX UART signals. Timing should not be critical if you send the data cyclically for every motors. This of course will take more work rather than buying two units of SCU21-V1 to get 4 RS232 ports.

Use both MouseDown and MouseUp action. On MouseDown, set the Point value to True. On MouseUp, set the Point value to False.