photovoltaic

Not exactly. To change the CPU name select No to the popup when you go online so your new name remains in your project. Place your PLC in Program mode and then select Controller -> Update CPU Unit Name.  

Any physical input or output that you want to use needs to be in your program so you can configure what it does.

It will run by default as it is Program0 and included by default. If you made a new program yes you would need to add it to a task.

If it is accomplishing the same logic then yes. To illustrate what's likely going on - and this is a common ladder logic mistake - any time an output coil is duplicated the bit it toggles will have the value given to it by the last rung where it is used when you are looking at it online. It will have the correct value given to it in between the duplicate coils but your HMI will be polling in between logic cycles so it will always get the value given to it by the last instance. Cross reference it and it should be very easy to track down. This should help show what I'm referring to:

For a bit to be true in a coil the coil must display green and have preceding conditions true as well. I think like IO_Rack said you're not running both simulators.

I'm not familiar with your program so I can't say for sure but when you toggle a bit that would be an output-type instruction (right side of the rung). There must be a section of code where you can toggle a BOOL true when the process is complete though I assume. Going to make up some logic to illustrate this - probably nothing like your program but hopefully gets the point across..  

Lamps operate using an expression. When the expression is true the lamp reflects the ON Color, and when the expression is false it becomes the Off Color. This expression can be any number of things but for your application you can just use the BOOL tag from your PLC.  If you have a tag in the PLC that indicates the process is complete make sure it is a Global tag and then add it to your HMI mapped variables. You can then type the name of it in the expression for the Bit Lamp.

When you're online you can monitor it:

In the sample program and manual for the ARCL library it appears they can and should be held on until completion is confirmed.

There will be no issues using EIP, FINS, and an HMI on the same port. Just make sure your primary task isn't taking up most of the time allotted.

That warning is not for your PLC, you only have 1 Ethernet port in the NJ101 an it has FINS enabled - you should be fine with FINS. For your Ethernet/IP settings you list the tag size as 100 in the PC and don't specify a tag name. In your PLC the tag size is 2 - tag name and size must match.

In general - 3rd party anything works great with Omron - except FSoE.. If you want to stick with FSoE get an Omron EtherCAT coupler and some safety IO slices. If you can do CIP safety (NX102 & NX-SL5X) then there are many remote IO options.

Most EIP drivers are explicit tag-based messages and yes, sticking to elementary datatypes can save yourself some trouble(just don't ask a Rockwell PLC for a BOOL). In Implicit connections your offset won't play a part in it though. If the size matches then the data flows!

The easiest way to check the size is to create a variable as either an input or output variable (under the Network Publish Column). Then go into your Ethernet/IP connection settings (Tools -> Ethernet/IP Connection Settings), double click on the Ethernet/IP port's IP address, then select Registration All. This will list all Input and Output variables and give you their size in bytes. Click cancel unless you are happy with the size. To work with Structures in Excel simply copy the parent Structure and paste it into Excel. When you are done copy from excel and paste into Sysmac. For EIP structures you will likely want to use the User Offset type as the default NJ offset type allots 32 bits to pretty much everything.

This means you have 100us to spare every Primary period. Your system task runs every 10ms along with 2 other tasks. You have 100us * 20 = 2ms to spare for 2 tasks and a system task which handles your NA comms, EtherCAT comms, and Ethernet/IP comms - that's pretty tight. I'm surprised your HMI doesn't lag already. As far as offset type goes NJ is optimized for your architecture but it will most definitely cause a size mismatch and cause everything to fall out of alignment as well. You could try using a byte array and then the instruction aryByteTo to map it to your structure. You're trying to apply a bunch of bandaids instead of addressing the root cause in my opinion. I understand it's not your machine but the scan time seems to have been overlooked from the OEM.

I'm unaware of a similar instruction in the CJs (but I'm not an expert). You're dealing with bits in a word on an address-based platform - I would just make 16 rungs to analyze the first bit that's true and report that number.

The writing is on the wall here I think - your primary task was nearing the limit before you added the additional code and connection. You need to offload your primary task or increase the period. What problem are you having with an In/Out declaration ?

Is this a batch weight or steady flow? Are you getting the weight from a load cell, analog, or networked device? Are there multiple weights involved? Are you looking to get the total for the day sort of thing?  

In the NJ PLCs the system task doesn't run in parallel. It will execute in the space between tasks and interrupt a priority 17 or higher task if needed. You do have some control over it (Operation Settings -> Basic Settings -> System Service Monitoring Settings). A good rule of thumb is to stay under 80% usage of your primary periodic task window. In your situation I would try to offload some code from the Primary if possible or increase the Primary task to 1ms (best solution IMO). Adding the new EIP connection will increase the service task time required which can cause a timeout error if it can't accommodate it. I don't recommend increasing the timeout detection or disabling it all together - this is the equivalent of turning up your car radio to drown out a squeaky belt. All of your tasks should have enough time to run in their entirety.   

A quick fix for this is to get your colleague to copy any 3rd party EDS/EDH files to a folder on a flash drive and then you add all of those EDS and EDH files to your EDS folder. EDS folder: C:\Program Files\OMRON\Sysmac Studio\IODeviceProfiles\EipConnection\Eds Restart Sysmac once the files are moved over and you will have all of their EDS files. With EtherCAT devices the ESI files do transfer with the project but not EIP.

For motion IO on these controllers the input and output numbers usually reside in control words of motion instructions - not actual bit-level addresses. Decode the control words with the instruction reference and you'll likely find they are pointed to those IO.

Have you tried using the RestartNXUnit function?

A few things that jump out: You need to assign the Port_ID variable to the sNXUNIT_ID variable in your IO Map. You Rec_Array should be much bigger. I would use BYTE[16] personally. 4 bytes is too small. Your order of operations should be: Clear buffer, send the ASCII 9 character, when new data is present then read it and decipher. It looks like the device needs to be polled by the ASCII 9 - it doesn't just send updates regularly. You can check for new data by assigning a tag to the CIF card's "CH1 Receive Data Exist" flag in the IO Map.  

I'm going to assume the software is a FINS master. All you need to do is assign addresses in the PLC. You will need Sysmac Studio to do this - you could get away with the 30 day trial. In your global variables under the AT column you simply assign an address to a variable like "%D123" and when your FINS master asks the PLC for address D123 the PLC will reply with that variable's value. A good free testing tool for FINS TCP/UDP is Etherway.

That's what I would do if I really didn't want a static IP on my controller. I'm sure you have a reason to go this route..