SERCOS Questions

I've recently began looking into the SERCOS interface and have a few questions. I would guess there are a few people are here with some experience with it.

Question 1: For communications between controllers and drives, does each product have to follow SERCOS standards so that IDNs are understood? I feel like this may have a fairly obvious answer of "yes", but it just seems a little different than what I've worked with in the past.

Say for example a drive is SERCOS certified, that would mean that drive would know to input certain information such as velocity status in a certain IDN for a controller to read?

Question 2: If I were to program a drive with certain parameters, would this be something completely separate from SERCOS? As in, SERCOS is just a way to read/write parameters of a drive but aren't necessarily required for programming a drives parameters?

Question 3: This question is regarding the initial set up of SERCOS communications. This image below shows the phases and includes a note for an ability to pause the initialization after phase 2 so that additional parameter IDNs can be sent for an application...

Why is this necessary? Why wouldn't someone just include parameter IDNs during initialization? This may be a specific question to G&L's PiCPro software. I simply don't know.



So any help?

bump

I think that you are way beyond most people already
I have only used SERCOS in a restricted environment - ie all from the one supplier eg rockwell so I never had compatibility issues

have you looked at secros.org and sercos.com?

SHibbard said:

I’m guessing from your statement “a little different than what I've worked with”, that your experience may be more in discrete I/O busses? If that’s the case, the big difference here is that Sercos was designed for two tightly coordinated, highly intelligent devices to talk with one another. Main intent was to facilitate the interoperability between motion controls and drives. There, common values such as commanded speed, position, torque, or actual speed, position, torque need to be exchanged in certain formats that can be understood by both ends (the intelligent drive and the motion control). This is more complex than the usual case with discrete I/O. Although the configuration of discrete I/O devices benefits from standard definitions of setup values, the operational values are often straight forward. Sercos supports that as well, but it is the simpler of the two tasks. The definition development by the Sercos Committee is quite through, and in fact is also used frequently with other field busses that lack such a common language definition.

To your question 1: Yes, a certified drive should as you state, know to put the value for velocity in a certain parameter that can be read cyclically. Not only the memory location (parameter numbers) but also the bit weighting and so forth.

To your question 2, better definition is needed as to what you mean by “program a drive” Sercos defines parameters that are read and/or written cyclically during operation (like updating a velocity command), or parameters that are used for setup of a drive (like scaling information). I suspect you’re talking about setup info. The setup info does not necessarily need to be setup through Sercos; it is the decision of the product manufacturer. It can be that a drive manufacturer decides to only allow changing certain parameters from a proprietary panel or software. However, good practice suggests it is best to allow access to these parameters also over Sercos. Since Sercos connects drives and other peripherals to a central control, that central control can be used as a programming device, monitoring tool, and parameter archival location.

To your question 3: Sercos is a highly deterministic, cyclic bus system. A number of timing and format parameters need to be setup before cyclic operation can commence. That occurs in phase 2. Until those timing parameters are setup, so-called cyclic operation cannot be started. The goal is to get to cyclic operation as fast as possible, as it is more efficient than polling (phase 1 & 2), hence the phase 3. A vendor can decide themselves what parameters need to be defined before progressing to phase 3.

Click to expand...

Thank you so much for replying. Very helpful.

Regarding my last question, why specifically would there be an option to wait for SERCOS phase initialization after phase 2 for the option to set up more parameters for cyclic transmission? That makes no sense to me. Why not just initialize every parameter/IDN you want to be sent cyclically during SERCOs phasing.

This might be a manufacturer specific question, but I can't understand why someone would want to pause sercos initialization to go then read ladder logic to look for additional parameter to send cyclically. Why not do it all at once?

Guess I didn't address that part specifically. Where did you pull that snippet from? I don't recall that wording anywhere in Sercos documentation. Could it be from an old G&L PiCPro manual? If so, they may have had a specific reason I am not aware of.