Siemens S7-1500, OB35 and Profinet question

[Peter Nachtwey]

One of my posts was lost due to the slow website updates.
BrtyanG's idea is OK if you know how to write a Luenberger Observer. That is a fix in in software solution. It will work but it is still covering up the problem and not fixing it.

It is interesting that this problem exists on other machines and they just haven't noticed.

The RMC controllers can control this application easily. The RMC controller comes with RMCTools that provides auto tuning and plotting that can show what is happening from scan to scan.

If you really want to solve the problem then contact [email protected] He is located in Edinburgh Scotland. We have a couple of distributors in the EU but they are not that knowledgeable.

In the future I recommend you use 1 micron resolution rods or better. I don't think the cost anymore.

 

[Tinine]

Are you using only a position reference? What about velocity and acceleration?


The resolution is for computing velocities and accelerations too. If your update rate is 1 ms, the minimum velocity you can detect is 5mm/s.

Ah-ha, someone actually addressing this point. I have searched and searched re: benefits of faster loop rates but not much is said.
I just came across some OMRON-PMAC blurb, boasting 5 axes in 25usec. Can this be of any practical benefit?
My own development, I'm an order of magnitude faster than the PMAC but is it going to make any difference when it comes to machine control (servo-motors and servo-valves)?


Rgds,


Craig

 

[Peter Nachtwey]

Ah-ha, someone actually addressing this point. I have searched and searched re: benefits of faster loop rates but not much is said.
I just came across some OMRON-PMAC blurb, boasting 5 axes in 25usec. Can this be of any practical benefit?
My own development, I'm an order of magnitude faster than the PMAC but is it going to make any difference when it comes to machine control (servo-motors and servo-valves)?


Rgds,


Craig

The OMRON-PMAC was designed by the Delta Tau Data guy named Curt Wilson if my memory is right. He is good.

The 25 microsecond update doesn't apply here because the feedback from the SSI MDT is not anywhere near that fast. Encoders for motors update instantly whereas MDT rods use a pulse and return pulse and the return pulse takes longer than 25 microseconds.

Also, this is a problem of synchronizing feedback to the control at even intervals. This is not a problem with encoders because they update instantly and the encoder chips are on the motion controller, not on some remote MDT rod.

A history note. I met the founder of Delta Tau Data way back in the 1980s at one of his seminars. His name is Dmetri Dmetri.

I can go into some history here if anybody is interested but I would start a new thread.

Back on topic.

Doomsword has a difficult problem to solve. I don't think he will solve it in software. He might but the solution will cost more in time and money that buying the right motion controller. We realized this a long time ago which is why we switched to a FPGA to handle the I/O. I can see that Doomsword's eyes were opened when he realized his problem actually existed on previous machines. What is sad here is that the PLC/automation guy often is put in no win situations due to bad design. They might just live with the problem and ignore it if has worked well enough on previous machines.

 

[Tinine]

I met Dmetri a couple of times. He was trying to take my business from Jacob Tal (Galil).


I would definitely be interested in the history.


Rgds,


Craig

 

[mk42]

You think the problem is that there are two 2ms timers and they go out of sync. Can't you do it with one 2ms timer. Call OB35 on receipt of the message from the Temposonic.

Not a dumb idea at all. That's what Profinet IRT does, syncs up the application clock with the bus clock. The PLC already supports it, but he has to make sure his IO and network do as well.