RT-8p8c - An ethernet based interface for LinuxCNC

So you are not enabling RTnet's TDMA discipline?
Seems not to be needed as the board does not talk unless asked, you may just daisy-chain several of these without collisions...

I wonder how would you manage the 100uSec ask-reply delay if you were to implement a closed-loop. You would ask on one iteration of the rt-thread and use the reply on the following itaration?

Regards,
Fernando

fmederos wrote:

So you are not enabling RTnet's TDMA discipline?

I'm not using TDMA. There's just a single "user" in this case.

Seems not to be needed as the board does not talk unless asked, you may just daisy-chain several of these without collisions...

Or have the board serve as a gateway to other devices so that there will be no network contention.

I wonder how would you manage the 100uSec ask-reply delay if you were to implement a closed-loop. You would ask on one iteration of the rt-thread and use the reply on the following itaration?

Start the sequence with a TX then RX with the initial read value discarded. Then adjust the reply delay such that by the time the READ thread starts a reply is already waiting.

[WRITE THREAD] TX -> reply delay -> RX [READ THREAD] --> Process --> [WRITE THREAD] TX -> delay -> RX [READ THREAD] --> ...

Regards,

GP

I see, the tunable delayed reply is good!
In fact what is needed is a delayed "measurement-and-reply" not just reply, so the data used by the PID routine is as fresh as possible.

Things might get complicated managing different delays when several boards are connected, unless ring-virtual-topology is used as you suggested...

Regards,
Fernando

fmederos wrote:

I see, the tunable delayed reply is good!
In fact what is needed is a delayed "measurement-and-reply" not just reply, so the data used by the PID routine is as fresh as possible.

Yes, it's a delay before measurement and reply.

Note that ~100us is tx and rx combined. This time can be reduced if the PIC32 workload is also reduced.

Things might get complicated managing different delays when several boards are connected, unless ring-virtual-topology is used as you suggested...

Regards,
Fernando

Play with one board at a time.

Do you have any particular reason for the selection of PIC? I assume because it was the one on the demo kit?
I'm thinking of a servo interface instead of steppers, which requires more hardware (D/A, encoder tracking) but I like the approach you've taken.

Doug

jimlas53 wrote:

Do you have any particular reason for the selection of PIC? I assume because it was the one on the demo kit?
I'm thinking of a servo interface instead of steppers, which requires more hardware (D/A, encoder tracking) but I like the approach you've taken.

Doug

I actually started with the enc28j60 board that I had before progressing to the fastest ethernet enabled chip that Microchip had.

I choose stepgen because I just want to control my MF70 mill. I don't like to use the thick LPT cable.

The other nice thing about PIC32 is the built-in DMA which helps a lot if you want to offload the processing to another chip/fpga. The PIC32 just serves as a high speed bridge to whatever driver board you want to use.

GP

I have several routers using stepgen and they work great (with the big LPT cable!). I just acquired an old SMT assembly machine which has a good X-Y ballscrew/servo setup, including the servo amps. So I need a servo control interface. I would be interested in testing your board/firmware on one of my stepper machines, which will help me get familiar with the code, something I'll need for a servo interface. Can I buy a board?

Doug

jimlas53 wrote:

Can I buy a board?

Once the hardware and software are stable and tested. Everything is still in alpha-stage. I haven't hooked it up to a real machine yet; the only connection it had is to my scope.

The real motivation behind this is to actually develop a working RTnet hal driver so that the big guys can come in and start making good stuff.

GP

I'd be happy with a bare board - I build SMD PC boards every day and do some PIC programming, so no problem there.

Doug