Advanced Search

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.

Is it recommended to use any FF1 with RioCore? It is defaulted to 0.0 in the generator but a lot of other stepper drivers seem to use FF1=1.0

Also would I need to use the P=250 at all or is that the best setting?

Either way, it is a Linux thing to recognize multiple fingers if your monitor supports it, so might be better to look in the Debian forums.

Thanks, that makes sense. R's must be built into the usb adapter.
I will add termination resistors and give that a try.

I flashed 7i96_pktv3d.bit to try out the modbus with a minimal config. I assume I will need updates to run the rest of my configuration?

My lathe has a 7i96 with rs485 connector.
Can I use ptkuart with my 7i92 and 7i92T if I use a ttl to 485 adapter and firmware updates?

Lathe uses a 7i96 with 7i85S and a G540 - 7i96p1_7i85dsdi.bit
Mill uses a 7i92 with 7i85S and 7i75 daughtercards, 7i92_7i85sx1sdid.bit 
Router uses a 7i92T with a 7i75 and a G540 7i92t_g540d.bin
 

I don't think I would trust a USB device under these circumstances. I would recommend you go back to XHC's website and look for a 433 MHz pendant that hard wires in to send/receive unit. After years  of use, these have never let me down 

Do you have a link to the one you use or a model number?

Here's the wiring information:  (just added to 7I96 manual)

RS-485 OPERATION

For 2 wire RS-485 applications, TX+ must be connected to RX+ and TX- must be
connected to RX-. RS-485 pair wiring is TX-/RX- to A and TX+/RX+ to B.

For RS-485 applications, 7I96 cards require two biasing resistors to establish the
non-driven state of RS-485 interfaces (MODBUS etc). The first resistor should connect
between +5V and RX- and the second between GND and RX+. Suggested resistor value
is 330 Ohms.