innoaloe

I use APR most of the time. To me SCL is a very weird instruction because the scaling result must be different format from the original (Binary to Hex, vice versa)

I see... well, that's to be expected though. There are miss-information here and there in some manuals. The Z924 was pretty old and only got 2 revisions, which I don't believe including revising the Siemens part. Nowadays G9SP is pretty much left behind in development since the new NX-Safety Controller is introduced

I checked the 7KM datasheet, and it is equipped with ModbusTCP function. In order to communicate you have to buy an Ethernet Slot CJ1W-ETN21, otherwise you cannot communicate to that meter. Omron also provide ModbusTCP Function Blocks that can be used together with the CJ1W-ETN21 to make programming easier. Regarding how to, since you're in India it should be easier if you contact Omron reps in India. They got 3 main offices in Delhi, Mumbai, and Bangalore. I don't know where you are, but local contact should be easier nontheless.

May he rest in peace... one of the important inventors who're not getting media attention. I remembered knowing him in name only during school exam...

I never program any Mitsubishi PLC, but just to give my perspective on the comparison since Omron also migrating to structured programming (let me short it as SP) :   SP do save development time. A lot of it, since you don't need to debug any miss-addressing, and all the FBs are there to help you do the job you need. As long as the FBs are well documented, there shouldn't be an issue to use them   For a same task SP does consume more memory compared to mnemonic programming. That's for sure since the language kind of translated twice during compilation.   I don't about SP being slower. In my case the SP is introduced on the newer PLC models which is developed only to use SP. The specs also upgraded to a faster CPU and larger memory. We don't use SP in the old models. Since you are comparing mnemonic and SP in FX-Series which is developed during mnemonic era, and also considering it is the low-end model, I doubt it has the capability to run SP smoothly. That might explain also why lots of your Function Blocks didn't work.   In the end the compiler also matters. Typically there are compile optimizations options that we can choose. Too much optimization sometimes results into weird behavior of the program. Also we will never know how good is the design of the compiler   In my case even in Japan we are migrating fast into SP usage, leaving the mnemonic ones. But I do know that many Japanese engineers (typically the older ones) avoid to use SP. It's kind of a trend in Japanese engineers to not use something that they don't know what's inside (things like Function Blocks), to which I disagree. Using standard FBs provided by your product vendor shouldn't be an issue since they guarantees the use.

I'd say keep it to yourself and sell that the knowledge should anyone ask you to do it. Hard work should be payed :D

Go look for IO Table Settings. You need to set it properly. Basically it's to register your ID262 and OD212 so the CPU can identifies the units prior to mapping the I/O address.

In my case only v1.19 available in the AutoUpdater list. I must say I'm impressed with the improvement to view both NJ and NA project windows at the same time

You should try to create a Sysmac Studio project with a PLC (either NJ / NX1) and an NA HMI in the same project. You will notice that Global Variables that you make in the NJ controller can be mapped to the NA (see Variable Mapping section in the NA part). And you should also try to create a Recipe in the NA project. When you're asked for the Ingredients, basically you need to put variables that will be used to fetch data from the Recipe. Typically this will be using variables that is previously mapped to the Controller, so that it can be used inside the PLC program. In order to fetch the values, you need to call WriteRecipeToController function by Visual Basic Code in NA.

I was wrong when I said this is not possible in Omron NJ. I forgot that a certain Omron software able to return the list of available Tags / Published Variables in the NJ. So I look onto it and found out that the service indeed exist. Just not stated in the manual

And yet... another bug... I kind of hate the way RnD team handling the situation these days... They should do thorough check before releasing anything. Of course bug will always be there, but connection issue with older firmwares is something basic that no one wouldn't expected to happen.

Happy to hear it worked fine :D

You need to buy one from Omron, duh...

That's good to know. Anyway, anyone had impression on the latest Sysmac Studio 1.19?  

The protocol you are sending to G9SP is FINS Protocol which is unique to Omron devices actually. In case of Omron PLC, the Unit Number part is used to identify which communication unit is sending the data. Since you're using Siemens you don't need to worry about the content, just keep it to 0. As for ServiceID, it is just like an Echo byte. The content ain't important. If you put 55 hex there, when G9SP reply back, you will get the same 55 hex. If you put 40 hex, you'll get 40 hex reply.

Okay, seems the example is still the same as my manual (Z924-E1-02, basically the second revision). I've noticed in 3-20 on the very first program line the additional bytes you're talking about. It inserts 25 80 C0 A8 FA 02, all in Hexadecimals. The first I noticed is C0 A8 FA 02 is the IP Address of G9SP as set in the example. If you convert all those into decimals you'll get 192.168.250.2. Also the first two bytes which is 25 80, if converted to decimal will results to 9600, which is the Socket Port Number used by G9SP Any UDP communication will require you to define the target IP and target Port, so I guess these two bytes is there for the FC5 function block parameter. The actual data being send is still starting from 80 00 02 00 part

Could you write the complete filename of your Z924 manual? Because I cannot seem to find any data format being shown in Z924 of mine (mine is Z924-E1-02.pdf). Or can you mention the page number in Z924 that states the data format?

But the Z924 manual did state the following on page 3-11. The same as what you are using I believe, so you should be good to go. Also page 3-13 give the settings used in the example (IP Address setting). Basically you just need to send/receive data through UDP Client using CP343. The data format is mentioned in the Z922 manual per se... you need to adjust it to match your application. I'm no Siemens expert so cannot help you on how to exactly program it in TIA

If I get it right, he wants to create new recipe without reprogramming the NA from Sysmac Studio. If that's the case you can use the AddNewRecipe function from the VB Code. It will generate a recipe with the current content of Variables you mapped to the HMI Recipe and you can give it a unique name. The new recipe will be saved on HMI Memory the same as if you add it from the HMI program.

If you're creating your NA program with the same firmware version as your actual NA firmware, there will be no warning about upgrading the OS AFAIK. It is only complimentary to upgrade if your program firmware version is higher than the actual hardware, since NA programs are not backwards compatible

In that case you are already sending a correct Service Code and Class ID. You just need to double-check the way you send your target address

Omron design center for Sysmac software in the end went back to Japan. I don't know how much of influence our European team can give to enforce these ideas though...

Omron doesn't create one. FINS is Omron protocol so it's understandable that they create the manual in detail for the FINS message. CIP on the other hand is open protocol managed by ODVA, so you need to search on their website (or just put their name in google). I have read one (forgot where the document is), but there are only packet structures written there. There are no example programs in C or whatever language. Regarding @saurav kumar issue, you mentioned that you managed to register a session. Just a hint, for CIP protocol when you register a session you will get a Session ID send from the connected EIP device to your CIP Client. You need to save that Session ID in your Client program, then for any next transmission you send (such as read variable or anything) the Session ID must be put in the Ethernet/IP header of the packet. Also, there is a tool by Molex Corporation called EIPTools which you can use together with Wireshark to trace the CIP packet if you need to. Both are free.

Well, I'm not sure what exactly your Safety Gate module is, but let's say it's single wire then the inputs should be some kind of photocoupler. In that case you can use the Dual Output without Test Pulse one.

Go look at Omron manual W465 (CJ/CS Ethernet/IP Operation Units Manual). It is the manual for both EIP Units like CJ1W-EIP21 and the CJ2M-CPU3[] or CJ2H-CPU6[] series regarding the Ethernet/IP function. Have a look at Section 9, Subsection 9-2 (Receiving Explicit Message). Omron CIP packet structure is all the same as any other CIP. You just need to adjust your Class ID, Service Code, etc based on the data that you'll find on that section.