Advanced Search

A Week of Python Purgatory: My Colorlight 5A-75B Still Thinks It's a Paperweight!
The Config (JSON files): I’ve attached my current JSON setup (j1.jpg and j2.jpg). I’ve spent a week tweaking these pins for my 6-axis setup, but I’m not 100% sure if LiteXCNC likes how I’ve named things or if my GPIO mapping is actually valid for the v8.2 board.

The Environment: My pip list shows I’m in a clean venv with LiteX-2025.12.

Questions for the Pros:

JSON Review: Can someone look at my modules and instances in the attached JSON? Does the way I defined axis_x through axis_c look correct for a 6-axis machine?

Watchdog: Is my timeout: 10000000 in the JSON too high, or is it okay for a standard setup?

Buffer Chips (v8.2): Based on my GPIO pin choices in the JSON, will I run into trouble with the buffer chips on this v8.2 board when connecting to 5V drivers?
The Current Setup:

OS: Debian 12 (Bookworm) with a Python Virtual Environment. (Debian is no longer silently judging me, but my Mini PC is).

Board: Colorlight 5A-75B v8.2.

Toolchain: Yosys and Nextpnr-ecp5 are installed.

Goal: A 6-axis CNC beast, controlled by Ethernet.
I have my pip list showing the full LiteX-2025.12 venv. Can someone please review my synthesis log to see why I am not generating a bitstream, even with yosys and nextpnr installed?

I’ve attached the evidence: my pip list, terminal outputs (json_1.png and json_2.png for the JSON files), and my which python3 output (proving I’m not crazy). Any advice from someone who’s survived a week in "Python Purgatory" would be amazing!

Thanks,
Jaae

Here are my updated files that work (for now, until I change them again)

 

Was ginge den vom rpi4?

Ich hab ein rpi4 mit 7i92 an einer emco vmc100.
Läuft super.
Latenz ist aber so lala.. daher wollte ich den für nen tischaufbau nutzen km sachen zu erproben.

An die vmc100 kommt n optiplex 3050m.

Halt stop, zurück

den TangNano9K kann man nicht vom RPI4 aus programmieren, dafür braucht man einen PC.

zum rumspielen ist denke ich, ist der TangNano9k ein guter einstieg,
im prinzip geht es auch günstiger, ber dann ist man extrem limitiert.

Aber es kommt immer drauf an was du machen möchtest, es sind halt nur dev-boards.

Ahaaa i have laying a 7c81... i use on my rpi4 a 7i92.

Other question

What is the cheapest fpga with which i can start? Can you recommand...

Ach qas laber ich hier auf englisch...
Was ist deiner meinung nach der günstigste fpga zum starten?
Stm32 black und bluepill hab ich... auch n radpberry pico usw..

Danke dir

nope, moving way slower than by hand. It´s not getting any position change at all, even with super slow acceleration/velocity

maybe the move is to fast or the resolution of the encoder too high for parport

Ok, I think I figured out why the label colors weren't changing. In Glade, I had a color defined in the label attributes. After I cleared that entry, then the color changing worked.

Now to work on my further modifications.

It worked for me in the virtual sim environment, debian 12, glade 3.4 installed and axis.mm sim. It was embedded as sidepanel. And the screenshots made when set example pin true/false. 

short version:

i put the ethernet cable in the rj45 socket

longer version:
i used the rio gateware and add an w5500 ethernet board to the spi pins:

 

Could you please explain how you connect the 7c81 via ethernet?

Hello,
i am currently stuck implementing a direct closed loop (2 axis lathe, parallel port, stepper motor, linear scale for closed loop).
The problem is: I do get the right position feedback, when moving manually (DRO display is correct) and i can see the correct encoder positions (in Hal-Scope: encoder.0.position). However, as soon as i try to move the axis, it starts to move and errors out with following error. If i look in the hal-scope, the "encoder.0.position" does not move one bit during the move (stepper is moving). 

--> Why does read out the position while idling but not while moving ?
Thanks 

When I tested the above code, it would change the text, but the color stayed black (no color changes)

Try with synctorefclock false, and see if your reset counter also counts up or not