Advanced Search

Did you download this through the pcnconfig or the browser?

I would think something like this would work, right? It has a PC817C, so I figure it is used to optically isolate the two circuits. What has me slightly concerned is that the listing (and many others) don't mention the fact that they are optically isolated (does this mean that it isn't?).

I see what you mean now about it not being properly isolated. I'll buy a cheap board off of amazon. In the mean time though, I just want to make sure I know how to set it up in general. I just want to know why I'm not getting anything out of it when I issue a s command.

tuxcnc wrote:

... but 12-24V is also used to power the home, estop and probe inputs on the opposite side of the board.

So no, BOB is not properly isolated for this case.

tuxcnc wrote:

it is safer to use a separate cheap Chinese PWM->0-10V board and a separate small power supply.

You should really, really take his advice, and be very careful with wiring.

I don't have my KBIC attached. I just wanted to see if I could read a voltage of 7 at 1400rpm from the terminals of the bob before I even attach it to the KBIC. The KBIC is not isolated, but the BoB is supposedly.

You are looking at the wrong side of the problem, BOB is not the part with issues, KBIC is, so you must check and be sure the inputs on the KBIC are galvanically isolated from the rest of the board.
If they are not isolated, ... well i would throw it in the bin, but you can get some kind of isolation probably, or just use a relay to run it at full speed using the relay on the BOB should do, most probably.
This is something you do not play with.

Just tried a 7I95T (Rev. A) with

(MD5 checksum)

f1c9dff646bc7496e0883b3d0afbc05d  7i95t_1v3pkt.bin

And all works as expected with a GS10 VFD

PktUART pinout for this configuration is:



 

This is with 2.9.10 and Master =2.10Pre (as of a week or so ago)

I also checked:

26b79f7bdef81b79ab3299925886b118 7i95t_1pktv2d.bin

and it worked as well, though it uses the other 7I95T RS-485 connection

You can use 7i80hdt_sv12d.bin (for 3 7I33s)
 Just enable 4 encoders and 4 PWMgens and the
rest of the pins will revert to GPIO (for the 7I37s)
 

Yes, I'm seeing exactly the same issues you're describing.

Adding M5 to on_abort.ngc does indeed work well in this case, although, as you say, it only masks the problem.

Nevertheless, it won't hurt to leave M5 in permanently.

I tend to think it'll be fine as all I'm using the 24V is for my homing switches and powering the board to let me control the spindle.

Regarding how I go about controlling the spindle, I'm not sure about how to do it. I have attached my hal file below. When I measure the voltage between the pins circled in red I get 0.01 Volts (even after I've homed my axes and and sent it an m3 s500).


 

Logthor wrote:

I believe my BoB is optically isolated ( this is the link to it). 
 

I just measured it. The 5V and 12-24V voltages are isolated from each other, but 12-24V is also used to power the home, estop and probe inputs on the opposite side of the board. If there is a risk of applying high potential to the 12-24V power supply, it is safer to use a separate cheap Chinese PWM->0-10V board and a separate small power supply. As for the 0-7V range, it is probably enough to scale the spindle speed appropriately (for example, setp pwmgen.0.scale 2000 instead of 1400, i.e. 1400 rpm will be 70% of 10V)

Hardware: 7i95T **rev A** (Efinix), LinuxCNC 2.10.0~pre0.6386.g3cd702c690
(buildbot deb), `hm2_modbus` + `mesambccc`. Slave: Delta C2000 VFD, 19200 8E1
RTU, address 1, parameters verified on its keypad.

Wiring per the 7i95T manual for 2-wire RS-485: TX+↔RX+ / TX−↔RX− bridged,
SG+/SG−/SGND to the drive, end-to-end continuity checked, bias resistors
fitted (2×2k2 to +5VP/GND), termination tried both ways (W23, rev A), both
polarities tried. A 7i84 runs error-free at 2.5 Mb on either serial port, so
transceivers, connectors and cabling are known good. A Saleae logic analyzer
at 24 MS/s sits directly on the RS-485 pair.

I believe I found three independent problems. As far as I can tell from the
forum, nobody has ever reported a *working* hm2_modbus setup on a 7i95T
(threads 51956 and 52858 both end without a success report), which would be
consistent with the following:

**1. TX drive enable polarity is not honored.**
Both official bitfiles (`7i95t_1v3pkt.bin`, PktUART v3 on serial 0, and
`7i95t_1pktv2d.bin`, v2 on serial 1 — md5-identical between mesact 2.1.8 and
the current mesanet.com 7i95t.zip) declare the TX enable pin as sec_pin 0x2,
which pins.c names "Drv Enable low". The hostmot2 driver never applies that
polarity: out of the box the RS-485 driver is **never enabled during
transmission** and the bus stays completely silent. Workaround found by
experiment: `setp hm2_7i95.0.uart.00.tx-drv-en.invert_output 1` — after which
the drive enable does toggle (visible on the analyzer). Should the GPIO
inversion be applied automatically by the driver from the sec_pin type?

**2. With DE fixed, no serial data ever appears on the line.**
Whatever is sent (hm2_modbus frames, or bytes pushed directly into the TX FIFO
via the raw interface at 0x6100 + sendcount at 0x6200), the analyzer shows a
**single solid low pulse per transmission, never a UART bit pattern** — even
for 0x55 payloads that should produce a dense alternating train. Pulse length
for an 8-byte frame is ~550 µs, which is ~88 bit-times at ~160 kbit/s, i.e.
about 8× the commanded 19200 (TX bitrate register readback is 483 for a
commanded 2304 baud, consistent with rate = baud × 2^24 / 80 MHz on the driver
side). So it looks like the serializer runs ~8× too fast AND the data path to
the TXData pad is stuck low during the burst. The slave never decodes
anything; the drive's own receiver decodes our DE edges as occasional 1–2 byte
ghost frames, which is what hm2_modbus then reports.

**3. The TX module eventually locks up entirely.**
After a series of hm2_modbus reloads and raw FIFO writes, the transmitter goes
completely dead — no pulses at all, not even via raw register writes — while
the watchdog has not bitten and all other functions (sserial, stepgen pins,
encoders) stay alive. Persists across hm2_modbus reloads; not yet re-tested
across a power cycle.

Also possibly related: at load time the "Drv Enable low" pin is listed on
implausible connectors (`TB3-16/TB3-17` for 1v3pkt, `TB4-22/23` shared with
TXData for 1pktv2d) where the .pin files say "Internal".

Has anyone ever seen the Efinix 7i95T PktUART actually transmit? Is a fixed
bitfile possible? Happy to test anything and to produce fresh analyzer
captures on request — this is for a lathe retrofit where the spindle VFD was
planned on this port.

Made an issue:
github.com/LinuxCNC/linuxcnc/issues/4465

Found some things in testing:

-I can see the spindle speed display go to 0 on first abort then immediately return to previous speed.

-The sim uses on_abort.ngc but removing it doesn't make a difference, but adding an m5 to the script will stop the spindle reliably. I think this is just masking the problem.

-I also note in the test program the initial line that starts the spindle is silently ignored.
I am not sure this is related.

-If I abort close to the beginning of the program - always restarts the spindle.
If I abort near line 500, 1000, or 1500 spindle stops.


Do you see the same?

I tend to think I'm making some sort of mistake. I currently am only making use of the PWM pin, do I also need to include pins for turning my spindle on and off as well?

I believe my BoB is optically isolated ( this is the link to it ). I just would like an example HAL file with my settings. When I measure with my multimeter after using stepconf, I get nothing even after I issue a command like s500 (my axes have all been zeroed).