SSI troubleshooting

ndzied1

Lifetime Supporting Member
Join Date
Aug 2002
Location
Chicago, Illinois
Posts
2,856
Hello,

Here's one I'm not sure has an answer. I have a customer w/ a problem with an SSI magnetostrictive feedback device. They are trying to commission a new machine and the transducer is not reading properly on a servo controller. The main question seems to be whether the device is giving a gray code or binary code.

At present, the device is buried deeply in the machine structure and we are trying to avoid massive disassembly to acces it. The customer asked me if I have some way to tell if it is gray code or binary. If I had a digital meter which I could program for either, I'd hook it up and just see which one worked but, alas, I don't. I'm going to the machine site Monday and have a scope (2 channel 100 MHz Tek handheld) but don't know if I'll be able to determine the gray vs. binary issue w/ the scope.

Anyone know of a way to do this with the oscilloscope?

Anyone in Green Bay, WI have a programmable SSI panel meter they are willing to loan out for a day?

Thanks,

Thanks!!
 
Maybe just help w/ scope triggering.

I found this diagram which shows the timing of the SSI clock signal. Inbetween the transfer of each number there is a pause interval (Tp) as shown below:

SSI.gif


However, I'm not an expert w/ the o-scope. Is there a way to trigger on the falling edge of the Tp signal shown? I'm only used to triggering on a voltage level, not a time.

With the data line on channel B, if I can store a number and move the cylinder and then store another number I might be able to determine whether I have gray or binary.

Comments? Suggestions? ... or should I just apply at Wal Mart and forget all this controls stuff?:p

Thanks,
 
How many signal lines are there from the SSI?

I can't claim to ever have done this, so I'm just thinking out loud here. With luck, someone with actual experience will chime in.

Are you able to identify each of the signal lines coming from the SSI?

Connect channel A of the scope to the least significant bit and channel B to the next most significant bit. Move the cylinder slowly. If the coding is straight binary, the pulse frequency on channel A should be exactly twice that of channel B. Now put the channel B probe on the next most significant bit. The channel B frequency should 1/4 the channel A frequency with binary coding.

With gray code, one and only one signal line changes state for each change in value, so the individual bits will not show as integer frrequency multiples of each other.
 
SSI (Synchonous Serial Interface) is just a clocked serial link, as opposed to the asynchronous link on PCs. I would be very surprised in the value coming back was Gray Code since there would be no advantage. The whole reason for Gray Code in parallel interfaces was to make sure that track and I/O switching time differences between the channels didn't cause incorrect readings. Since this is a serial transfer from a magnetostrictive device neither of these is a concern. So I would be surprised if the value was Gray Code.

What kind of numbers are you seeing? Are you seeing any numbers? Are the indrementing/decrementing at all? Are you sure it is an SSI interface as opposed to a triggered timed pulse interface (which is very popular with magnetostrictive sensors)?

In the greater scheme of things I think you are more interested in the data line than the clock line. However, given the length of the transfer I don't think you will get a whole serial transmission on a single screen. But at least you could see if the data line is changing during the transmission, which you would expect.

I'm in Brillion, about 20 - 30 miles south of you. If you want to bounce some ideas back and forth send me a PM here or email me at [email protected] and I'll see if I can be of some help.

Keith
 
Lol

I just love it when I hear about people that install MDTs and they don't record the info off the MDT head before they install them. Someone needs a scolding. (n)

The obviously isn't one of those new rods where you can read the info from the MDT rod over the SSI lines.

Yes, you should be able to tell the difference between gray code and binary using a O-scope. You need to move the actuator slowly. If you see the digital pulse counting in a binary pattern then it is a binary rod. The binary most siginicant bits will not change very quickly whereas bits will seem to change randomly using gray code.

Are you sure the number of bits is properly configured?

Norm, always record ALL the rod data off the head before it is installed. The 100 mhz scope can easily see the bit pattern.
What you want to do is use both channels. You want to trigger off the clock and monitor the data on the other channel. Use the voltage on the clock to trigger the readings. Each pulse or clock signal will look like a string of 24 or 25 bits and the clock frequency is going to be around 400Khz so each clock will be about 2.5 microseconds long so set your sweep to about 10 or 20 microseconds per division.

ndzied1 said:
Comments? Suggestions? ... or should I just apply at Wal Mart and forget all this controls stuff?:p

No, training, tech support and tools make a big difference.
 
Norm, the first thing I would do is find the brand/model of the device and get the manual and verify it is wired properly. There are so many variables involved, an SSI device could be 6, 8, 10 or 12 wire and could use Binary or Gray code protocol, 8 to 17 bit operation and programmable...it just depends. Technically the system designer should know some of these details or have them documented, especially the wiring.

In general there will be 2 power wires + and -, 2 clock wires, 2 for data and possibly another for direction (encoder).

I have a page that offers basic info on absolute encoders using SSI; http://www.patchn.com/absolutencoder.html#5
 
I found a half way decent description of SSI if anyone is interested:

http://www.sick-stegmann.de/sickstegmann_de/about/eigenmarken/ssi/en.toolboxpar.0005.file.tmp/SSI_Produktinformation_Englisch.PDF


Keith,
Signal is SSI and the controller they are using does require a Gray code. I suspect that the internals were all set up that way in the past and since SSI w/ gray code are readily available they stuck with it in the newer generation of controllers. The ones they have newley released are selectable for gray code or binary.

Peter,

That is what I was goig to try to do with the scope but I got a call this morning and they went ahead and disassembled the machine to get the transducer out. Indeed, the P/N shows it is a Binary output. They recieved a spare from stock which was also Binary output. Unfortunately, the controller only accepts Gray code.

It's funny working for a distibutor, this is one of our "good" customers. They did not even buy the transducers from us although they are a brand we carry. They actually purchase an assembly with the transducer pre-assembled into a cylinder of some sort by a different distributor and they had used them in the past so they stuck with that source. The machine goes into a foundry so the cylinder around the transducer is not a working hydraulic cylinder but just for protecting the transducer. I was not involved in the design at all and in fact, I have never even seen the machine.

They did buy the controller from us and, of course, when they first had problems blamed the controller.

I am in the Chicago area as is the design office of our customer. The machine is being assembled and comissioned in Green Bay, WI, 4 hr. north of here. They hire another firm, the one in Green Bay, to do the build and assembly then their engineers go up to commission it. I can only guess (but with a 99.9% confidence level) that no one bothered to power up the encoders with controller before they were "buried" in the machine to see if they worked.

When they first called on Thursday afternoon and explained things to me I said everything points to an encoder problem but they had it in their mind that the controller was bad. I spent all day Friday on the phone with them and was scheduled to go up there Monday to help them (they were going to pay for my time, unless of course, somehow the controller was at fault). All along, I am asking what the actual data format of the tranducer is?... ah, we have to call the other distributer. Did you happen to ask them the manufacturer and p/n for the transducer?... ah, we have to call them back.

In our part of the business, as distributors, we don't get to do much scolding. I chalk it up to trying to build good will and set the stage for future sales. For instance, when they called me today, Saturday, they said they couldn't get in touch with anyone at the other distributor... yet they have my cell phone number which I answer no matter who calls regardless of the day and the home phone number of the salesman from our company.
 
p.s.

Thanks to all for your suggestions. Ron, I should have looked on your site first for the SSI info. 🙃

Anyway, the trip is off until they can find the right transducer but I think that will solve all their problems (with the current system anyway).
 
Self inflicted wounds.

What is funny is I can do a pretty good job of guessing who all the players are in this. :) What the rest of you should realize is that Norm sells Bosch Rexroth and their hydraulic motion controllers. Norm represents the competition when it comes to motion controllers. I/we make hydraulic motion controllers too. I am hoping that some day Norm will see the light but until then....

ndzied1 said:
Unfortunately, the controller only accepts Gray code.
You need a controller that accepts both binary and gray code. :)

ndzied1 said:
They did buy the controller from us and, of course, when they first had problems blamed the controller.
Of course they do. It is their way of getting you to fix their screw ups. We can capture the data from the encoder. No need for a scope. No need to be there. They just need to e-mail the raw data and we can see by the way the data changes whether it is binary or gray code. Then we just need to set a gray/binary code configuration bit. Although it is just easier to flip the gray/binary bit if the position aren't correct.

Norm, do you see the light yet? Oh, well.

ndzied1 said:
I can only guess (but with a 99.9% confidence level) that no one bothered to power up the encoders with controller before they were "buried" in the machine to see if they worked.
A very costly mistake, but it happens all the time. I have similar stories too.
 
Peter Nachtwey said:
What is funny is I can do a pretty good job of guessing who all the players are in this. :) What the rest of you should realize is that Norm sells Bosch Rexroth and their hydraulic motion controllers. Norm represents the competition when it comes to motion controllers. I/we make hydraulic motion controllers too. I am hoping that some day Norm will see the light but until then....

First, I didn't mean to hide who I work for. Just making the post general because the problem really wasn't brand specific. In case any one is wondering, the controller in question was a 2 axis Bosch Rexroth HNC. The recently released HACD cards allow you to switch from gray to binary quite easily. The transducers are Balluff.

Like I said Peter, working for a distributor is funny. It's not a matter of "seeing the light" as you say. If the only thing we sold from BR was controllers then that might be one thing. We carry the entire industrial hydraulics line, the pneumatics line and the aluminum framing line. And BR is one of the few companies left that gives its distributors exclusive territories. If it happens in Northern Illinois or Northwestern Indiana and it's Bosch Rexroth hydraulics it come through us. This works so well that the BR Hydraulics distributors even get together and work on joint projects. We can do this because we are not competing against one another.

So, you bet I'm loyal to them. You don't see anyone working for Motorola carrying a Nokia phone, even the contractors (of which there are many nowadays).

I have no qualms about using your controllers where a Rexroth doesn't have the requried features and yours does. We have recently quoted an RMC for a 6 axis stepper application. If an animation house called us for a hydraulic project I'd call up Rick (one of Peter's salesmen) in a heartbeat. Likewise if the customer specified a system that required ethernet. But if I need Devicenet, Profibus, CAN, SERCOS, or Interbus then I have that covered with Rexroth.

I'll say it again, working for a distributor is different than working for an OEM or maintaining equipment in a plant. Our first approach is to use the products we represent. It has to be. It's why we exist. You might not think a thing exists but if a Rexroth controller was more suited to an application than an RMC, but the RMC would still do it there is no way in the world you would offer the customer the Rexroth unit. We don't push products on customers that don't fit the application. We obviously offer superior support of the products as demonstrated in this post... even helping customers with products we haven't sold them if we have the expertise.

In case anyone might get me wrong. I like Peter. I have the utmost respect in his knowledge of controls, especially PID system and specifically with a focus in hydraulics. I also respect him as a valuable member of PLCS.net. I hope the respect is reciprocal.
 
From my old experience with SSI encoders for Rexroth Intramat controls, they all used Gray code.
I don't remember any binary encoders.
 
Peter Nachtwey said:
I am not talking about gray and binary code. SSI rods just mean the data is acquired synchronous to the clock. What else needs to be synchronous? There are synchronous and asynchronous SSI MDT rods.

Are you talking about whether or not the interrogation pulse of the MDT is synched with the clock pulse of the SSI interface?

By definition, the SSI part is always synchronous. On the standard MDT's the pinging of the wave guide is continuously repeated but not necessarily in sync with the clock of the controller. Synched MDT's synchronize the pinging of the wave guide with the Clock pulse from the SSI interface. According to Balluff:
The internal interrogation of the S_ _ _ _B version is synchronized to the externally supplied clock pulses. This configuration results in a more uniform, predictable data update rate, and is better-suited for highly dynamic closed-loop servo applications. Like the standard version, the S_ _ _ _B version is EEPROM linearized at the factory.




Disclaimer: I work for a distributor that represents Balluff.
 
It could be semantics

Norm thats why I mentioned there are variables, some are programmable and the features can be changed...it depends. What Peter is saying is that the measurement can be synchronous or asynchronous, there is a difference.
 

Similar Topics

Hi all, I have an application coming up where I have a motor that runs forward or backward to adjust the linear position of a machine component...
Replies
6
Views
1,297
I have an application where I need a single SSI encoder to connect to both a safety controller (SICK Flexi Soft) and a general-purpose PLC...
Replies
3
Views
2,092
I'm being asked to bid a control system using Siemens S7-1500 controllers, which I don't have any experience with. The digital, analog, and...
Replies
5
Views
2,660
Hey Guys, I am trying to use an SSI encoder for the first time and having problems getting any data from it. I am using a 1738-SSIM23 Armorblock...
Replies
6
Views
3,986
hi. i have a AB PLC5 communicating to a Control Techniques Unidrive SP via MODBUS. the Unidrive is connected to an absolute encoder via SSI. the...
Replies
3
Views
1,615
Back
Top Bottom