Advanced Search

Search Results (Searched for: raspberry)

  • whyme
  • whyme
04 Jul 2025 18:59 - 04 Jul 2025 20:19
Replied by whyme on topic Raspberry Pi 4 with Mesa 7c81

Raspberry Pi 4 with Mesa 7c81

Category: Driver Boards

so a stiff pulldown to fight the pullup of the mesa card for the inputs?

I am using 7c81_5abobx2d firmware with BOB boards on P1 and P2.

Edit:
I did a little bit of digging.
- The relay pin P17 is IO7 of the Mesa ports, which is on the edge of the pull resistor array. I could desolder the array and put it back on shifted by one to remove the resistor of the pin.
- On the BOB there is a 10k pullup array on the relay pin. but the signal comes through a via in the middle of the pullup resistor and the 74HC... I could cut the trace between the via and the resistor to remove the pull up on the BOB
- solder in a pulldown resistor on the BOB (if for whatever reason the flat cable between the Mesa and BOB gets bad).
  • PCW
  • PCW's Avatar
04 Jul 2025 15:59
Replied by PCW on topic Raspberry Pi 4 with Mesa 7c81

Raspberry Pi 4 with Mesa 7c81

Category: Driver Boards

The 7C81 only has the option of all pullups and all pulldowns
on its I/O ports.

Simplest solution would probably be to add a stiff pulldown (say 620 ohms)
on the relay I/O pin. There is a firmware option for fixed parallel port type I/O
but currently its global (not per port), This firmware makes the parallel port
output pins default to outputs instead of inputs at startup or watchdog bite
What firmware are you using?
  • whyme
  • whyme
04 Jul 2025 14:57
Replied by whyme on topic Raspberry Pi 4 with Mesa 7c81

Raspberry Pi 4 with Mesa 7c81

Category: Driver Boards

Maybe a stupid question, but how do you use the relay on those cheap MACH3 BOBs with the 7c81?

For the inputs to work I need to enable the pullups on the 7C81.
But enabling the pullups makes the relay close as soon as the BOB is powered.

Ideally I would want the relay to be open until linuxcnc is started and I tell linuxcnc to close the relay.

But the relay closing by default due to the pullups makes it unusable, or did I miss something?
  • Will_cnc
  • Will_cnc
03 Jul 2025 19:13

Step By Step Help Needed . EL8 Leadshine to PI 5

Category: EtherCAT

Hi all,For context: I'm currently building the control system for a Samurai 120 CNC machine (please see the attached photo).Machine electronic hardware configuration:
  • 3 × Leadshine EL8 EtherCAT servo drives
  • 2 × 400W Leadshine motors with optical encoders and battery backup
  • 1 × 400W Leadshine motor with motor brake, also with optical encoder and battery backup
  • 1 × Beckhoff EK1100 EtherCAT coupler
  • 1 × Raspberry Pi 5 for control
Current progress:
  1. Successfully installed LinuxCNC on the Raspberry Pi 5
  2. Updated to the latest version
  3. Installed CIA402 using Rodw’s guide
  4. Configured the Pi as an EtherCAT master
Where I need help: I'm struggling to understand how to configure LinuxCNC to communicate with the servo drives in a basic setup.From what I understand, LinuxCNC relies on three main configuration files:
  1. .ini
    – Loads the user interface and references the
    .hal
    file
  2. .hal
    – The Hardware Abstraction Layer, which defines machine characteristics and connects components
  3. .xml
    – Extracts and defines information from the servo drives
I found Marco Reps’ GitHub repository, which uses a similar configuration. I downloaded all the files and attempted to launch LinuxCNC using the "el8" configuration, but it failed to load.
 Could someone please provide a step-by-step  on how to configure Linux CNC for my current setup? Any help would be greatly appreciated! 

I intend on eventually using the probe basic user interface as I an touchscreen this would work well with. https://samuraimachinetools.com/cdn/shop/files/IMG_9964.jpg?v=1722652171&width=1445
 
  • nejiman10
  • nejiman10's Avatar
02 Jul 2025 14:03 - 02 Jul 2025 14:13

LinuxCNC with RIO (FPGA) SPI Issue: Unexpected 'HXHP' Response

Category: General LinuxCNC Questions

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:
import spidev
import time

SPI_BUS = 0
SPI_DEVICE = 0
SPI_SPEED_HZ = 25000  # 25 kHz

spi = spidev.SpiDev()
spi.open(SPI_BUS, SPI_DEVICE)
spi.max_speed_hz = SPI_SPEED_HZ
spi.mode = 0b00

try:
    print("Sending dummy byte 0x00 to read response...")
    result = spi.xfer2([0x00] * 8)
    print("Received:", " ".join(f"0x{b:02X}" for b in result))
finally:
    spi.close()
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.















 
Displaying 301 - 305 out of 305 results.
Time to create page: 0.594 seconds
Powered by Kunena Forum