Advanced Search

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.

You write, 
iocontrol.0.emc-enable-in = TRUE (from remora.SPI-status)
The correct form is 
setp iocontrol.0.emc-enable-in = TRUE (from remora.SPI-status)
or 
iocontrol.0.emc-enable-in = 1

To pinpoint the error, you would need to provide your configuration.

The OS support for multitouch is there, or can be enabled.
What about qtdragon? Does it know how to handle multitouch events or geastures?

Dankeschön. Ich werde das heute Nachmittag mal ausprobieren

Ne hab ich noch nicht gemacht , aber nativecam ist schon recht schön , hat mir aber auch schon ein paar stunden an Nerven und grauen Haaren gekostet , ich werds mir mal anschauen . Danke

These are just default values that work on all my machines.