Advanced Search

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.

Sorry, I dont follow, what Syntax error are you referring to?

Hello everyone,I hope this is not a trivial question — I am still learning the Linux input stack and QtVCP internals, so please excuse any misunderstanding on my side.I am running LinuxCNC with QtDragon HD (QtVCP) on Debian RT.
My touchscreen hardware supports 15-point multi-touch (confirmed on Windows).
On Linux, the device is detected as.What I would like to achieve is:

• Two-finger pinch for zoom in the 3D preview
• Possibly two-finger rotation/pan gestures

​​​​​​​Any guidance, even high-level direction, would be greatly appreciated.​​​​​​​Thank you for your patience and for the excellent work on LinuxCNC.​​​​​​​​​​​

Connected CommanderSK VFD RS485 to 7i96 connector.

Docs at linuxcnc.org/docs/2.9/html/drivers/mesa_modbus.html state:6. Hardware ConnectionThe Mesa serial ports have separate pins for Tx and Tx pairs. For RS422 Modbus RTU communications these should be connected at the Mesa card Tx+ to Rx+ and Tx- to Rx-.Note that there are differing naming standards for Modbus pins. Typically Rx+ and TX+ will connect to the B- pin on the modbus device and Rx- and Tx- will connect to the A+ pin, i.e., +/- will appear reversed.

Is RS485 wired the same way?
 

My working USB/485 dongle solution connects:
RJ45                 USB Dongle
2 EIA485+          A+
3 0V                  GND
7 EIA485-          B-

So I have connected EIA485 to Mesa TX- and RX-, EIA485- to Mesa TX+ and RX+, 0V to Mesa GND.
​​​​​
I set up CommanderSK.mbccs to simply read the software version from the vfd. This fails with a "Received PDU too small, size=4"
I have tried hal_types HAL_FLOAT, HAL_U32 with the same result.

Any hints before I bring out the scope?

Hast du dir mal PyNGCGUI angeschaut? Es gibt eine Beispiel-Sim-Config "gmoccapy_pyngcgui"

Thanks Tuxcnc - I tried to replicate this with the SPI-fields of remora-spi. (minus the external pin) Unfortunately the behaviour stays the same. Besides looping in the external e-stop does it do something different in terms of iocontrol states?

Sounds good. I will try it. Thank you.

Das ist fuhr die Mesa 7i77,

Had a milling session, not very long. XHC didn't crash. Doesn't say much, so I'll continue using libusb_fill_interrupt_transfer().

Ok no testing. Interesting to see how it goes, and if the firmware in the dongle is to blame.

Try
M3 $1 S1000
Since LinuxCNC 2.8 (i think) there is built in support for multiple spindles, the $n should be the G-code controlling the spindle number where n is the spindle number starting from 0 (zero), so $0 is the default first spindle, then $1 is the second spindle, etc.
linuxcnc.org/docs/html/examples/spindle.html
linuxcnc.org/docs/stable/html/gcode/othe...ec:set-spindle-speed

Finngineering wrote:

... I prefer to call the USB part the dongle and the actual handheld device the pendant.

That is the usual naming since the dawn of "security dongles" started by software companies to prevent copying software and later adopted by some banks, and naming them something else... forgot what exactly, but dongle prevailed.

Yes, unless somebody have better terms, I prefer to call the USB part the dongle and the actual handheld device the pendant. In case of the wired version, I would presume all logic is in the pendant and the "USB part" is only a connector.

The problem for everybody else than myself is that you might have different hardware/firmware version. And if you overwrite the factory firmware with this new firmware, you can no longer go back, because you don't have the factory firmware. I could give you the factory firmware that was in my dongle, but it could be different than what is in yours. The firmware can be extracted (like I have done), but its tedious.

Anyway, I think its a little bit early for public beta testing. I will make some improvements and see if it appears stable over time. Maybe there could be some way to do at least a partial readout/verification of the factory firmware through USB.

Missing file