DMU 50M retrofit 99% done, Z axis falling on brake release

freemoore wrote:

I just had a very similar issue with a Yaskawa servopack drive on the Z axis of a Morbidelli. I tried adding `z-brake release delays via hal and had no luck. What eventually worked was finding a parameter in the servo drive that had the same purpose, something about keeping the control loop active so many milliseconds after the servo-ON signal or brake-ON signal was received. Perhaps your drive has similar? good luck!
 

Honestly, this sounds very reasonable and I've been trying to track such a parameter down for a while now. But my Simodrive is so old, it isn't supported by Simocom. I have to chug through manuals in the hopes of finding the correct one and the correct parameter. Been trying, but it's often conflicting information that I find, since Siemens don't publish specific manuals for a specific model, but general manuals for the entire product lineup... I will definitely keep searching, though.

It is probably worth noting that before we took out the original TNC 310 there was no such issue. So I would assume no parameters are corrupted or something of the sort.

RotarySMP wrote:

On my older MH400E, with Indramat drives, I made the mistake of adding a relay to give LinuxCNC co-control over the vertical axis brake. The original Maho design is that the Indramat axis driver solely controlled that brake. I had the opposite behaviour to you, where instead of dropping, the drive fought the brake during the period I had my finger on the machine start button.
Once I removed the 19K2 relay I added (second schematic in this post) the behavior worked correctly.
forum.linuxcnc.org/12-milling/33035-retr...0e?start=1740#340651

From the schematics you shared it I don't see the brake control circuit.Could it be that your brake control should be left to the axis driver alone?
Cheers,
Mark
 

Thanks for the feedback.
I haven't attempted to do anything like that. I'm not sure it is even possible for the brake control to be left to the axis driver itself. From what I see (on my untouched original DMU 50M too) the brake/release is nothing but an output signal from the controller to the drive. I don't think the drive itself is capable of handling such logic, or at least that wasn't the original machine manufacturer's intention. I will look into it, though.

Oh, also, my braking/release signal is a single one for all 3 XYZ drives. Is it possible to try and separate them electrically? Most likely. I'm not sure that's a good idea, though.

stenly wrote:

radom wrote:

I release z axis brake 0.2s after motion.motion-enabled and it works with my simodrive,
when does this servo power on signal becomes true? are you sure you are not releasing the brake before pid is working?
 
I don't think this is the issue. I checked just now to make sure. With me pressing F2 (which is also linked to the CNC ready signal going from the Mesa to the drive), I can clearly see the PID enabled and also motion.motion-enabled.

My AC power on button and circuit is separate from the Mesa entirely in an attempt not to have to reverse engineer the emergency stop, which is on the same board originally.

So my startup procedure is essentially:
LinuxCNC startup, LinuxCNC power on (F2), manually pushing the servo AC power on button, a signal returns to the Mesa board from the drive when AC power on is successful, that signal is linked in HAL to the brake release after a short timedelay.

In many cases, this works just fine. In many, Z falls through. Sometimes after a slight delay, so just when you think it's started up properly and the servo is holding the motor, it still falls through 10 seconds later.

Thanks for the suggestion, though!
How exactly is your servo AC power on handled? My Simodrive is sort of old, as you may see — the servos are 6SN1118-0AD11-0AA1 and the control board is 6SN1121-0BA11-0AA1. 



 

mine are from 1992 (mill) and 1997 (lathe) and judging by the pictures your simodrive looks like new compared to mine, but I had both power supplies repaired and also main spindle drive for lathe and Z axis drive for the mill
red led H1 axis fault is on page 83 and 84 from documentation
adegis.com/media/asset/eb8a4b2af69aebb3f...84e8f10fe17ff0ed.pdf
you can try swapping z and x drive motor connection (and encoder wiring and everything else) to see if it's not your drive that is failing
you said linuxcnc doesn't know that a fault occured so you don't get following error in linuxcnc??
I first power everything, then F2 only sends enable signal to the drives

 

stenly wrote:

Oh, also, my braking/release signal is a single one for all 3 XYZ drives. Is it possible to try and separate them electrically? Most likely. I'm not sure that's a good idea, though.

Now I'm wondering if you are looking at the correct thing
is there anything in the electrical diagram as "Z achse bremse"?

radom wrote:

stenly wrote:

Oh, also, my braking/release signal is a single one for all 3 XYZ drives. Is it possible to try and separate them electrically? Most likely. I'm not sure that's a good idea, though.

Now I'm wondering if you are looking at the correct thing
is there anything in the electrical diagram as "Z achse bremse"?

Yes, I probably worded myself confusingly. The *signal* for the brake is a single one for all 3 axes, but the brakes themselves are separate.I am attaching pictures of the electrical diagram that mention it. One is Motorbremze Z-Achse and at the other instance is Reglerfreigabe Z-Achse. Assuming the Regler (regulator) is supposed to interface the brake?

Regarding your other post, thanks for pointing out the relevant part of the docs of the controller. LinuxCNC triggers a following error if my FERROR value is set accordingly, yes. But there seems to be no relation between the following error and how much the axis falls — less than 10mm or so, which the encoder tracks correctly. The drive itself catches it and locks it. From what I see with a multimeter on the Mesa, LinuxCNC tries to compensate for this by sending a crisp 10V to the analog out of the axis to try to get it back into position, but it obviously can't.

If your machine is similar, I'd be curious how you have it set up to power it on in such a way. AC power on does not latch if 6K2.2 CNC-Betriebsbereit (CNC Ready for Operation) is not on. I have said CNC-Betriebsbereit signal linked to halui.machine.is-on so that it triggers when I press F2 power on. After which I can press AC power on and it latches, after which the brake is released.

Is this wrong? Thinking about it, maybe it'd be a good idea not to peg that signal to F2? I will try having the CNC-Betriebsbereit signal linked to something else on LinuxCNC startup, so that F2 can be nothing more but an analog out enable to the drives.

Haha, well, that didn't work. I setp the signal to be 1 at all times. I think I will leave it like that, as I definitely observe the other machine with the original controller NOT dropping it at any moment, even on an emergency stop press. But either way, it didn't help.

I even tried connecting the wire to the 24V power supply directly, so that the signal will always be high no matter what. No result.

Lately what I've been noticing is that the machine is usually capable of starting up the first time, but the axis falls through on trying again after an emergency stop. Is this a clue of some sort?