ColorCNC Colorlight 5A-75E/5A-75B as FPGA controller board

More
11 May 2022 04:57 - 11 May 2022 05:02 #242571 by romanetz
No, my plan was just to compile colorcnc firmware for Xilinx platform. A lot of changes is needed to original firmware to implement Mesa on RV901T platform: at least, move here udp/ip stack, say as from Alex Forencich github: github.com/alexforencich/verilog-ethernet
Now about uncommanded motion. I consider that it's necessary to implement some kind of a state machine like in ethercat: IDLE-> (transition by command) PREOPerational<->SAFEtyOPerational (process data available, no control) <-> (forward transition by command, backward transition by timeout) OPerational
And all boards must follow such set of a predefined commands. Say like in left corner of the attachment.
Attachments:
Last edit: 11 May 2022 05:02 by romanetz.
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
11 May 2022 07:28 - 11 May 2022 07:29 #242585 by TOLP2
Thanks for the poster, that is a nice one to keep in mind for further improvements.

At this moment there is a state machine in LitexCNC (not in the original colorcnc), however it is simpler then the EtherCAT one:
  • IDLE: Watchdog is timed out, all inputs / outputs are in safe state and the stepgens are stopped;
  • INIT: The master requests header information to verify the configuration of the card and firmware. The watchdog is still timed out and the outputs stay in safe state and stepgen stopped.
  • RESET: The master sends the reset signal to the FPGA and verifies it has been correctly received. This ensures the stepgen counters are reset to a known state, preventing uncommanded moves when the HAL-cycle starts sending data. The watchdog is still timed out.
  • ACTIVE: The master reads data from the FPGA, processes it (by using other components) and at the end of the cycle sends the commands back to the FPGA. The watchdog is being petted and after a pre-defined time-out (1,5 ms in the examples)
  • WATCHDOG_BITTEN: When the watchdog times out the inputs and outputs go to safe state and the stepgens are stopped. Depending on the settings, the stepgens are stopped gently (with keeping acceleration limits in mind) or harsh (stop direct).
At this moment the state-machine goes from top to bottom when LinuxCNC or the HAL is first started. An improvement is still required on the transition between WATCHDOG_BITTEN and ACTIVE. At this moment as soon as the watchdog is petted again, the movements start again. Theoretically the machine did not loose steps, but I think it is better to stop the machine and enforce a RESET state.

So: safety is in the design of LitexCNC and I really do appreciate people actively seeking for safety!
Last edit: 11 May 2022 07:29 by TOLP2.
The following user(s) said Thank You: Bari, besriworld

Please Log in or Create an account to join the conversation.

More
16 May 2022 21:06 #243112 by TOLP2
Small update:
  • the firmware is now supporting RV901T and the various ColorLight cards;
  • the firmware is expanded with the support for encoders (up to 32 :D). This new module has a different layout then the previous layouts, making it faster and more concise to develop;
  • the target of this project is known: my Emco5 will become the test-bed for this firmware, an example of the config is given below. Have to say, it makes the configuration as easy as it can get.
{
    "board_name": "test_PWM_GPIO",
    "baseclass": "firmware.boards.RV901T",
    "clock_frequency": 50000000,
    "ethphy": {
        "tx_delay": 0
    },
    "etherbone": {
        "ip_address": "10.0.0.10",
        "mac_address": "0x10e2d5000000"
    },
    "gpio_in": [
        {
            "name": "rapid_override_reset",
            "pin":"J601:7"
        },
        {
            "name": "feed_override_reset",
            "pin":"J601:8"
        },
        {
            "name": "spindle_override_reset",
            "pin":"J601:9"
        }
    ],
    "gpio_out": [
        {
            "name": "rapid_override_active",
            "pin":"J601:15"
        },
        {
            "name": "feed_override_active",
            "pin":"J601:16"
        },
        {
            "name": "spindle_override_active",
            "pin":"J601:17"
        },
        {
            "name": "stepgen_shared_enable",
            "pin":"J600:39"
        }
    ],
    "pwm": [
        {
            "name": "test_otherwise_no_compile",
            "pin":"J601:36"
        }
    ],
    "stepgen": [
        {
            "name": "stepgen_0",
            "step_pin": "J600:38",
            "dir_pin": "J600:36",
            "soft_stop": true
        },
        {
            "name": "stepgen_1",
            "step_pin": "J600:34",
            "dir_pin": "J600:32",
            "soft_stop": true
        },
        {
            "name": "stepgen_2",
            "step_pin": "J600:37",
            "dir_pin": "J600:35",
            "soft_stop": true
        },
        {
            "name": "stepgen_3",
            "step_pin": "J600:33",
            "dir_pin": "J600:31",
            "soft_stop": true
        }
    ],
    "encoders": [
        {
            "name": "rapid_override",
            "pin_A": "J601:7",
            "pin_B": "J601:8"
        },
        {
            "name": "feed_override",
            "pin_A": "J601:9",
            "pin_B": "J601:10"
        },
        {
            "name": "spindle_override",
            "pin_A": "J601:11",
            "pin_B": "J601:12"
        },
        {
            "name": "MPG",
            "pin_A": "J601:13",
            "pin_B": "J601:14"
        }
    ]
}

While developing I found a few bugs which need to be resolved: when no GPIO, PWM or Stepgen is defined, the firmware crashes as it is trying to create a register with a width of 0. At this moment at least one of each have to be defined. When the encoder driver software is finished, I'll tackle this problem as well.

Another nice feat: I'm making a hat for the RV901T, so all the stepper drives, switches and user input can be connected easilty. This board also contains a FTDI232 chipset so it can be reprogrammed on the fly. 
The following user(s) said Thank You: kwarup, romanetz, svb

Please Log in or Create an account to join the conversation.

More
17 May 2022 12:58 #243152 by romanetz
Which version of Xilinx tools do you use?

Please Log in or Create an account to join the conversation.

More
17 May 2022 13:48 #243161 by nickXX
TOLP2, are you planning to create a wiki and release the files fotr the hat, when it's ready?
I can solder and have the experience with programming different chips, but as for the colorcnc, it's pretty hard for me to understand what's going on and what needs to be done ...
Guess a few of us are open to donating, to motivate your work further ..
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
18 May 2022 15:00 #243275 by TOLP2
@ramonetz: At this moment I've downloaded version 13.6 for Windows. The space requirements for the latest version of the studio seems a little bit too crazy with 15+ Gb. I also saw it has been renamed to Vivaro. 

With the version I've installed I didn't have luck yet to produce a bit-file which seems to work on my RV901T. I did upload the bit-file for blinking the LED and this worked, so I know for sure my JTAG-hack on the board worked. Have to say the toolchain for the 5a-75E (josys) is much more friendly and imposing on a starting user.

@nickXX: all files are available on my github . Within the README-file I want to put all the information to upload the firmware and on how to compile the driver. The first part I still have to write, the latter has been doen (although it can use some expansion on the pins). Because I'm now supporting two different board-types (Colorlight / EPC and RV901T / Xilinx) and it turns out they require different toolchains, I like your idea to convert the README to a wiki.

The design for the hat will also be published in the repository. It will be made in KiCad. The design will not be very refined, because':
  • my soldering iron and my skills do not suite SMD well, I lack experience;
  • my preference is to make the hat with my router (own production), which also limits the minimum size of the pads. I have to do some experiments on how small I can go.
What I can do off course is to upload the basic design with the location of the headers J600 and J601, so one can base their design on the correct location of the headers.
The following user(s) said Thank You: besriworld, nickXX

Please Log in or Create an account to join the conversation.

More
19 May 2022 09:54 #243327 by romanetz
Well. I managed to compile my version of firmware for RV901T. Still not sure if all timing constraints are met, because I'm not very good with ISE. Today I'll make some tests.

Please Log in or Create an account to join the conversation.

More
19 May 2022 14:29 - 20 May 2022 21:33 #243347 by TOLP2
Romanetz, can you please give some guidance how you managed to compile:
- which version of ISE did you use?
- did you only use the verilog code produced by Litex, or did you need any other file as well.

Would love to se a screenshot of your ISE environment.

Edit: after some tinkering I managed to compile the firmware for the board. Turns out Litex dumps some erronous clock constraints at the end of the file. I've deleted those lines and now it compiles. I can read the magic and reset the board. However, as soon as I start reading data from the board, it stops working :(. Have made some changes to the firmware, so I have to cross-reference with the 5A-75E to see whether the problem is board specific or that I broke the firmware...

Edit 2: In the branch encoder  I have now a working firmware and driver which supports the modules GPIO, PWM/PDM, stepgen en encoders. Now it is time to write down for everybody how to hook this thing up for their specific setup and perform some tests. I suck at soldering SMD, still have to test anything with inputs...
Last edit: 20 May 2022 21:33 by TOLP2. Reason: Added some more progress
The following user(s) said Thank You: nickXX

Please Log in or Create an account to join the conversation.

More
21 May 2022 10:31 - 21 May 2022 10:34 #243468 by muvideo
Hi,
I'd like to try your implementation on real hardware.
Maybe I lost something but I'm having difficulty to build the firmware.
I have latest Litex on my machine (Ubuntu 20.04 python 3.8.10).
once cloned the branch "envoders" from your repository in my home directory
then
cd LiteX-CNC/
python3 -m firmware examples/5a-75e-hello-gpio.json

It fails with this message:
 
File "/home/fabio/LiteX-CNC/firmware/soc.py", line 86, in __init__
    super().__init__(config)
  File "/home/fabio/LiteX-CNC/firmware/boards/colorlight.py", line 66, in __init__
    super().__init__("5a-75b", "6.0", config, sys_clk_freq)
  File "/home/fabio/litex/litex/litex/soc/integration/soc_core.py", line 386, in __init__
    SoCCore.__init__(self, *args, **kwargs)
  File "/home/fabio/litex/litex/litex/soc/integration/soc_core.py", line 121, in __init__
    LiteXSoC.__init__(self, platform, clk_freq,
  File "/home/fabio/litex/litex/litex/soc/integration/soc.py", line 747, in __init__
    self.logger.info("FPGA device : {}.".format(platform.device))
AttributeError: 'str' object has no attribute 'device'

So I'm making some mistake, what is the supposed way to build the firmware?
Thanks.
Last edit: 21 May 2022 10:34 by muvideo.
The following user(s) said Thank You: TOLP2

Please Log in or Create an account to join the conversation.

More
22 May 2022 19:49 - 22 May 2022 19:54 #243573 by TOLP2
Thanks for trying it out. You didn't do anything wrong, you found a bug in initializing the colorlight-board. I fixed the problem I would like to ask you to please test again.

The supported board types are:
  • 5A-75B:
    • version 6.1:
      "baseclass": "firmware.boards.ColorLight_5A_75B_V6_1"
    • version 7.0:
      "baseclass": "firmware.boards.ColorLight_5A_75B_V7_0"
    • version 8.0:
      "baseclass": "firmware.boards.ColorLight_5A_75B_V8_0"
  • 5A-75E:
    • version 6.0 (can also be used for version 8.0):
      "baseclass": "firmware.boards.ColorLight_5A_75E_V6_0"
    • version 7.1:
      "baseclass": "firmware.boards.ColorLight_5A_75E_V7_1"
  • RV901T: 
    "baseclass": "firmware.boards.RV901T"
If you find any trouble getting the firmware running, please let me know here and I will explain or fix. Also, I started to work on the wiki. I will give a shout when it is finished.
Last edit: 22 May 2022 19:54 by TOLP2.
The following user(s) said Thank You: nickXX

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.234 seconds
Powered by Kunena Forum