Andrei Blagaila

SECS/GEM Communication

13 posts in this topic

Hy guys,

Has anyone ever used SECS/GEM with mitsubishi PLCs? I don't really understand it and maybe someone know better how it works.

Thanks.

Share this post


Link to post
Share on other sites

I'm not very good at this and not very familiar with it, but what specifically are you wondering about? What is it that you don't understand?

Share this post


Link to post
Share on other sites

I'm interested in understanding how the PLC communicates with the Host. I'm guessing that there is some kind of shared memory where both PLC and host write. I'm using for example ladder diagram in GX Works 2. What kind of variables do I use for the communication part? B kind? I've been trying to study the Q50UDEHCPU (the one i'm using) and it's manual to understand where is it's shared memory and if that is the solution because as I wrote above, I'm new to SECS/GEM and don't quite understand how it's supposed to work with Mitsubishi.


Thank you

Share this post


Link to post
Share on other sites

SECS/GEM is more of a standardized way of communicating with SECS/GEM compatible HW. The "standard" CPU's for ladder programming (like your Q50UDEH CPU) does not support communication using SECS/GEM - you'll need a C controller (like Q06DCCPU-V) and according to Mitsubishi's documents you can perform SECS/GEM communication.

This would be a lot easier if you could explain what you are connecting too on the host side. What are you going to communicate from/to the PLC? Why do you need SECS/GEM communication? Please inform us what you want to communicate with (e.g. a regular server, MES system, SCADA system and so on), and why you specifically want to use SECS/GEM.

Share this post


Link to post
Share on other sites

So I have a project already done with Q50UDEHCPU and it has SECS/GEM implemented in it already using ladder. I'm trying to understand exactly what happens here because at the moment it's all a blur. I have on the rack a WinCPU and on older models of the machine i have a PPC that runs a custom software written in C that takes data from the PLC and sends it to the host via Ethernet. I'm not sure what it communicates with on the host side because i'm doing a kind of reverse engineering on the software in order to understand it. But i'm stuck at the moment on this. Where do I store in the PLC the information that is sent to the PPC and then to the host? The CEIDs and SVID's for each CEID. Basically i send an event to the host when the machine passes from a state to another. I don' know if I explained well or not. I want to understand how it communicates. A basic principle involving also the variables where i store the information. Maybe an example. Thanks

Share this post


Link to post
Share on other sites

It's a bit hard to understand:

Just now, Andrei Blagaila said:

So I have a project already done with Q50UDEHCPU and it has SECS/GEM implemented in it already using ladder


You say that you have a PLC with SECS/GEM implemented using ladder code, but then you say you have a WinCPU with a C program that fetches data from the PLC and sends it to the host via Ethernet. How do you know that the PLC has the SECS/GEM protocol? My initial guess would be that the C program in the WinCPU has SECS/GEM to communicate with the upper layer system (host), while it reads out data from the lower level system (PLC) using a more standardized way for PLC's - like a PLC<->SECS/GEM gateway. But again, this is only guessing from my side.

 

Just now, Andrei Blagaila said:

Where do I store in the PLC the information that is sent to the PPC and then to the host?

It's almost impossible for us to say where you should store information for an existing program. How can we know what kind of data is sent to the PPC? In the PLC you have lots of memory for storing variables (e.g. M, D, L, R, W and so on....). We don't know what data the PPC fetches from the PLC (the PPC can fetch any memory area it wants)... Since you're reverse engineering you will have to debug the program in hand, the PLC is not a "specific" or predefined unit, so it can be programmed to anything (within it's limits).

Share this post


Link to post
Share on other sites

I'm not asking for an exact answer just some guidelines to help me narrow my search. I did not know that the WinCPU or PPC can fetch any data it wants from the PLC. That is usefull to know. I just have to understand how it does that at the moment in order to be able to modify it in the future.

Share this post


Link to post
Share on other sites

 

I agree with Kaare_t.

The WinCPU just looks like a Windows embedded PC.  If this is the case it will probably be doing the SECS/GEM protocol and using a bespoke interface to the PLC. Can you log into the PC? You may be able to see how it is communicating with the PLC. If I was doing this I would use an OPC Server on the WinCPU simply because all the time and effort I would spend creating the SECS/GEM interface to the PLC (in C or whatever) could then be reused on any PLC without having to recode it (just point the OPC server to a different PLC). If an OPC server is installed it probably also has a standalone client you can use to see all the registers in the PLC it is using.

Share this post


Link to post
Share on other sites

I agree with @Nightfly.

Log into the WinCPU to check for any information there. As said the WinCPU can fetch any data from the PLC, hence your reverse engineering would probably have to be done in the WinCPU, and not in the PLC CPU (again just guessing). Check out what happens in the WinCPU and then we'll look at it from that point of view.

Share this post


Link to post
Share on other sites

Not sure but I think Mitsu just uses the C CPU and has software written for it, like they did for Ethernet/IP.

Share this post


Link to post
Share on other sites

Hello Guys,

I want to add some info specially regarding what kaare_t  say:

PLC communicates with the host via SECS/GEM standards is  SEMI industries, the communication is done via PLC Bus and it has a driver QBFFUNC32.dll that is used by PPC.exe.

The source code for PPC exe is in C, and has defined these functions for communication via BUS:

QBF_Open - Opens the bus.

QBF_Close - Closes the bus.

QBF_X_In_Bit - Performs X 1- point input.

QBF_X_In_Word - Reads X in word unit.

QBF_X_In - Reads specified No. of bits from specified bit position of X.

QBF_Y_Out_Bit - Performs 1- point output for Y.

QBF_Y_Out_Word - Writes Y in word unit.

QBF_Y_Out - Writes specified No. of bits from specified bit position of Y.

QBF_Y_In_Bit - Inputs a Y point. Perform 1- point input for Y.

QBF_Y_In_Word - Reads Y in word unit.

QBF_Y_In - Reads the specified No. of bits from specified bit position of Y.

QBF_ToBuf - Writes to buffer memory of intelligent functional module.

QBF_FromBuf - Reads from buffer memory of intelligent functional module.

QBF_UnitInfo - Reads the module configuration information.

QBF_StartWDT - Sets the interval of the WDT and start up the WDT.

QBF_ResetWDT - Reset the WDT.

QBF_StopWDT - Stop the WDT.

QBF_ReadStatus - Reads CONTECWinCPU module information (LED, error, etc).

QBF_ReadStatusEx - Reads CONTECWinCPU module information (LED, error, link device refresh time etc)

QBF_ControlLED - Control LED s on CONTECWinCPU module.

QBF_Reset - Reset the bus.

QBF_WaitEvent - Wait for event interrupt from programmable controller program ((P).GINT instruction).

QBF_WaitUnitEvent - Wait for event interrupt from module.

QBF_ControlProgram - Control execution of programmable controller program.

 

This is how the communication is done with Q50UDEHCPU processor.

 

 

Share this post


Link to post
Share on other sites

Hello Guys

The SECS-II(SEMI Equipment Communication Standard 2), which is also recognized as SEMI E5, is used by the semiconductor industry as a protocol for communication between devices involved in manufacturing. SECS-II is a layer above HSMS & SECS-I.

SECS-I and HSMS outline how the communication takes place (such as over RS-232C or Ethernet), SECS-II defines the format and content of messages that can be sent over SECS-I/HSMS.

The SECS II explains the message structure between equipment and host. SEMI E5 standard is a large library of messages – a few of which have redundant functions with different message structures. Most equipment supports a limited subset of these messages. Some equipment defines custom SECS-II messages that are not part of the SEMI E5 standard.
GEM standard requires only a few subsets of messages. Few SECS-II message transactions can be initiated by the Host and few can be initiated by equipment. And few may be initiated either by host or equipment.SECS 2 messages should have the correct party and correct message format as defined by E5.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now