Advanced Search

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.

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. 

Thank you for testing. The output indicate that the program was working as expected. The firmware is not exactly the same as mine, but it looks similar. How big differences/similarities there are would require disassembly comparing those. I can see that at least memory addresses are a bit different. Here is the output from mine (not the real dongle, I put the factory firmware on another device which has bootloader version 2.40):The addresses and sizes are close to each other, but not exactly the same.

Because you have bootloader version 2.40, I believe we would be able to read out the firmware through the bootloader. But it requires creating a similar program for that as the one we just used. And to get to bootloader mode, a 10k resistor needs to be added to the pendant. So maybe better to wait until I have tested the new firmware a bit more. And then you could read out the firmware and flash the new one at the same time, if you are still interested at that point.

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?

Thanks a lot !
It's working fine but the jog speed is vert low.
Jog slider @max
Can you tell me where to change this value ?
Thanks
Marco

In your XML file, you have opened the root tagtwice.

Hello,
I would appreciate a second thought on an issue I experience with the 7i92TM. The board is connected to a G540. After installing linuxcnc 2.9 and some rearrangement of hardware, I only have two axis left functioning (z and y) and switches (connected to the G540) are not recognized anymore either. 
Swapping the wiring to other axis transferred the functioning axis over to the new config. 
I was suspecting the G540 to be at fault and swapped it against a chinese parport BOB I still had around.
After flashing the 7i92 with the correct file (5abobx2), the new setup shows the same behavior as before which pretty much rules out the G540. 

I am running out of ideas and hence considering the 7i92TM being the problem. 
I measured the voltage of Step+ to ground and Dir+ to  ground with Linuxcnc running directly at the BOB. Results as shown below. 

Xstep: 5V
Xdir: 0V
Ystep: 5V
Ydir: 5V
Zstep: 5V
Zdir: 5V
Y2step: 0V
Y2dir: 0V

Is my assumption correct that, since z and y axis do have 5V on step and dir an the others don't, that these are outputs are physically damaged?

Thanks for your help. 


 

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!

Hi This is a linuxcnc report after changing codes in custom panel files.Can someone help me ?

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

So I spent much of yesterday using Claude to help me figure out the AT903's modbus setup. I found and used OpenModScan from here: github.com/sanny32/OpenModScan along with a waveshare USB-RS485 adapter to communicate with the mystery VFD. I'd recommend OMS, it installed straightforwardly on my linuxcnc PC and proved easy enough for me to use as a newcomer to modbus. 

I found several versions of a manual that relates to the 'AT900 series' VFDs, (i.e. AT901 and AT903) some with odd unicode, have attached one of the more readable ones. 

I scanned about 16000 addresses in the modbus holding register range and found that there are around 16 blocks of used addresses, each starting at the beginning of 256-bit blocks, which correspond quite closely (identical in many cases) with the manual's function groups as coded e.g. P01.01 is at 0x0001, P17.00 at 0x1000. I've confirmed that I can write to some of those addresses as well as read them; I have not yet managed to find the address that accepts actual run and frequency setpoint commands - the freq. setpoint address shown in the manual is read-only.  

Spreadsheet is attached - copies of the function groups per the manual, next to their modbus addresses, in case this is useful to anyone else.

Anyone with time to have a quick look, who has a deeper familiarity with modbus standards, I'd be grateful to get some idea of the most likely command register addresses. 

By the way, if this post is in the wrong forum section, I apologize. Please move it to the correct one, if possible.

Hey all,

For some time now I've been retrofitting a Deckel Maho DMU 50M to work with a Mesa 7i97t and 7i84u over LinuxCNC. I'm so close to being done with the machine, but there's just one major issue that I can't get past — the Z axis falls about 10mm on servo power on and brake release 3 out of 5 times on average, making it impossible to work with the machine. It falls no more than 10mm before what I assume is the emergency stop kicks in and catches it, leaving me with a bright red LED on the servo drive and no way to power the machine on without a hard restart.

Does anyone have any clue what I'm doing wrong? As I hope is obvious from the HAL (line 266), I am releasing the servo brake a short delay after the servo power on signal arrives (the AC power on and emergency circuit is separate from the Mesa entirely). I've tried connecting it with an and2 gate to what should be a signal for emergency circuit ok too, to no avail. What irks me is that this issue is inconsistent. I can't find a surefire way to get the axis to fall through or to work properly, it's different each time and every day.

I don't think it's the PID configuration that's causing this, as even on a stupidly incorrect calibration that makes the machine oscillate, whenever the axis falls through, it does so in the same way — as if it is merely doing so under its own weight.

I've exhaustively measured the analog out to the drive from the Mesa and don't see any relation to the issue. If I were to spam jog in a positive direction to get an analog out of 10V before AC power on and brake release, you'd expect the axis to shoot out at max speed upwards on release, but no. It falls through in the same way.

LinuxCNC itself, the Mesa and even the main servo controller seem to have no indication or idea a fault has occurred. The only indication is the red LED that I can't really find exact documentation for.

Coincidentally, I have the exact same machine with the original Heidenhain TNC 310 handy. Measured said signals there with an oscilloscope as well and I don't see the original controller handling it any differently than from what I am doing.

I'll attach the HAL, INI and some pictures of the servo drives and the relevant pages of the electrical documentation.

Many thanks for taking the time to read this.

Here is what happens when I run the tool. My whb04b is from the era when they just stopped selling the predecessor.The output from the command is attached,

I had a feeling that it could be possible to read out the factory firmware from the dongle due to some bugs in the firmware. And that is indeed the case, at least for a partial readout. It is possible to read the firmware from where the USB device descriptor is stored in program memory until and including the bootloader. I added this tool to the github repository:
github.com/finngineering/whb04b/blob/mas...s/firmware_readout.c
While I think this tool should be safe to use, I give no guarantees. With a partial readout, I could compare that to my firmware, and if it matches, the likelihood that the whole firmware is the same is very high.

Actually, now that I've done this, I remember that there is a much easier way to read out the firmware from CH55x with bootloader version lower than 2.50 (which is the version that my dongle has). The above tool should print the bootloader version, and if it's less than 2.50, I could maybe make a tool to read out the firmware through the bootloader and over USB.