Advanced Search

my board is now here too.

I also managed to get the LEDs to flash,
but the FPGA with Vivado is very complicated for me.

In addition, the bridges you have to set on the board are extremely small (R1485 / 25Mhz clock).

somehow it is also possible to clock via PS (ARM-Core),
but I can't get it to run so easily with the console tools

Flashing via JTAG doesn't really work either, I can only write to RAM.

I'll keep playing around with it, but please don't expect RIO integration.

Otherwise the FPGA is cool with its dual-core ARM running Linux
 

This circuit will prevent the spindle direction from changing so long as the spindle is not stopped:
www3.langdonstaab.ca/Spindle%20direction%20circuit.png

(Just an idea)

First off, my apologies for not responding earlier, I've been waiting for my 7i76u to be returned before moving forward plus chores around the homestead have been a hinderance for time.

As Peter said the board was tested and found within specs. Out of an abundance of caution, I ordered as 24 v laptop PS which I received it this morning. After putting it on my scope and monitoring it for several minutes I found only glitches of < .1 v while holding an output voltage of 24.5 v which was the same with the previous PS only at 24.1 v.

Next I reinstalled the MESA board and mapped the X,Y and Z limits to inputs 0,1,2 and the probe to input 4 with EStop on 5. Restarting LCNC with sserial set to 20xxxxxx I monitored the fldvoltage and the four analog inputs. 0,1,2 (the limit switches) reflected the fldvoltage at all times. The probe voltage (input 04) fluctuated wildly between 0-3 v until I grounded the probe plate at which time it matched the other three inputs.

Next step was to reset sserial back to 00xxxxxx and restart LCNC. None of
first four inputs responded as expected.

After shutting down and powering off the machine I remapped X/Y/Z limits, Probe and EStop inputs to inputs 04-08 respectively. After power up and restarting LCNC the Limits and EStop responded as expected, however the Probe on input 07 did not. LCNC sees it as triggered on startup and going low upon contact. OK, shutting down LCNC and changing the HAL file to invert input 07 then restarting pin 07 still responds the same, i.e. high on startup and going low when contact is made.

My next step will be to rewire all of the inputs as sourcing inputs by moving the power legs from the +24v buss to the GND buss, change HAL to reflect the changes and retest.

Taking a break for a couple of hours then I'll let you know of my progress.

Tpm is disabled
Also the device is visible in:
lspci | grep 2718

Good to know, the only thing is that as soon the linuxcnc is open there is no lights activity at the Ethernet port,

Si

New video

I had forgotten that the spindle  ratio setting was not set correctly. I had 8192 in the ini file, the new value is 14700. 

Not sure about pncconf, but LinuxCNC deliberately blocks card access when running.

I'm using 2.9.4

Did you select "Arc Voltage" on the encoder menu on the TB1/TB2 tab?
 

Current Situation and Probrem
I am trying to establish stable SPI communication between a Raspberry Pi 4 and an ICE40UP5K FPGA (IceShield) using LinuxCNC and the RIO framework.
While basic SPI communication seems functional outside of LinuxCNC, I am currently encountering unexpected behavior during runtime: the system consistently logs "WRONG DATA" with "HXHP" as the received header.
My goal is to understand what SPI response LinuxCNC expects from the FPGA, and how to configure both ends to ensure correct communication.

Environment

•     Raspberry Pi 4
•     LinuxCNC version: 2.9.4 (same behavior also observed in 2.9.3 and 2.8.4)
•     OS: Official LinuxCNC 2.9.4 Raspberry Pi 4 Bookworm image
•     FPGA: ICE40UP5K-SG48I (IceShield)
•     Clock source: Since gpio is not available on Bookworm, I use pigpiod to generate a 5 MHz clock on GPIO 4:
       

  #!/bin/bash sudo pigpiod pigs hc 4 5000000

    I also modified spiflash.sh to work with pigpiod under Bookworm

FPGA Status

• The Verilog design (rio.v) is written to return the SPI response header "data" (0x64617461)
• The FPGA’s LED is blinking and SPI data is returned via external tools. This suggests the FPGA is operating correctly with the supplied clock.

SPI Test Using Python
To confirm basic SPI functionality outside of LinuxCNC, I used this script:This consistently returns "data" from the FPGA, suggesting that low-level SPI transport is functioning properly.

Behavior in LinuxCNC

• In the rio_readwrite() function, logging shows the SPI response always begins with "0:02" (0x30 0x3A 0x30 0x32)
• However, the LinuxCNC log reports "WRONG DATA" with the string "HXHP" (0x48 0x58 0x48 0x50)
• I did not find any logic in the Verilog code that would return "HXHP"
• I suspect that "HXHP" is generated internally by LinuxCNC when an unrecognized or malformed header is received

Observations

• SPI communication appears to be working, and the FPGA is returning a response
• However, there may be a mismatch between the header format LinuxCNC expects and what the FPGA sends
• LinuxCNC may be replacing the unrecognized header with "HXHP" as a default or fallback

Questions

• Where in the LinuxCNC source is "HXHP" generated or substituted? Is this a fallback response?
• Is the "0:02" sequence a standard header sent by LinuxCNC under the RIO configuration?
• What header or message structure (e.g. MSGID) is LinuxCNC expecting from the FPGA?
• Are there documented or example SPI response formats compatible with riocomp?

I would appreciate any advice or clarification.
I can provide Verilog and riocomp.c sources if helpful. Thank you.















 

No, they are isolated optocoupler outputs rated 100 VDC and 50 mA max.
So the enable outputs may be used in place of relay contacts if the ratings
are not exceeded and polarity is observed.

Did you set HOME_SEARCH_VEL to 0 as required by Index-only homing?

Otherwise homing B will search for a home switch before searching for index.

linuxcnc.org/docs/html/config/ini-homing.html#_configuration

Thank you for your response. The line pwmValue = self.h.hal.get_value('pwmgen.0.value') is working well.

However, I’m having trouble with the QPushButton (or Action button). I’m not receiving any callback when it’s clicked.

Thank you very much for the quick response, it will be very useful to me...

Tanks

How do the 7i97t drive enable pins work? Do they supply a voltage?