Remora - ethernet NVEM / EC300 / EC500 cnc board

More
19 Jun 2025 16:08 - 19 Jun 2025 16:29 #330518 by tuxcnc
I can't drive EC500 spindle encoder to work.
(The counter works properly, but index not. I can use encoder's index output as ordinary I/O, but this not satisfied me due to delays)
I suspect, this never will work, because the used code is wrong way.
I'm developing similar project (but only spindle support) on STM32F103, and my code seems works properly.
Here you are most important fragments:
[code]//********************************************************
This is a fragment of code from other project
Not for copy/paste, only for explanation
//********************************************************

// EC500 side
// fb. prefix means variables will send from EC500 to hal component

struct fbPacket {
    float raw_encoder;
    float encoder_latched;
} fb = { 0.0, 0.0 };

fb.raw_encoder = encoder.getCount();
void index_ISR1() {        // interrupt handler
  fb.encoder_latched  = encoder.getCount();
}

//********************************************************

// Hal component side
// fb. prefix means variables received from EC500
// index_ena is i/o hal pin for connect to spindle.0.index_enable
// pos_scale is hal input pin
// period is LinuxCNC global variable
// pos and vel are hal output pins
// Not need anything else for synchronising spindle

float old_pos;
float latched_enc;
float encoder_latched_old;
float delta_pos;
float delta_time;
struct FB {
    float raw_encoder;
    float encoder_latched;
} fb = { 0.0, 0.0 };

            if  ((encoder_latched_old != fb.encoder_latched) && (index_ena)) {
            latched_enc = fb.encoder_latched;
        old_pos = (fb.raw_encoder - latched_enc);
            index_ena = false;
            }
            encoder_latched_old = fb.encoder_latched;

   pos = (fb.raw_encoder - latched_enc) / pos_scale;
   delta_pos = pos - old_pos;
   old_pos = pos;
   delta_time = period * 1e-9;
   vel = delta_pos / delta_time;
   
//******************************************************** 
[/code]
 
Last edit: 19 Jun 2025 16:29 by tuxcnc. Reason: edit the code

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

  • scotta
  • scotta's Avatar Topic Author
  • Offline
  • Platinum Member
  • Platinum Member
More
19 Jun 2025 20:35 #330531 by scotta
Hi, which module have you been trying to use? The software Encoder module or the QDC module? Both support the index pulse detection and encoder count latching so LinuxCNC can acquire the index position count.

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

More
19 Jun 2025 22:48 #330537 by tuxcnc

Hi, which module have you been trying to use? The software Encoder module or the QDC module? Both support the index pulse detection and encoder count latching so LinuxCNC can acquire the index position count.
 

Hi.
QDC.
The encoder_raw code is good and there are only hardware problems (optocouplers and RC filters cut the bandwith).
But this is very bad idea to send encoder's index pulse by ethernet.
Let's make calculations.
3000 rpm and 1 ms base_thread is 18 degrees accuracy - not acceptable.
The solution is send not index, but raw_count lathed at encoder's index edge interrupt routine.
There is in your code, line 321 in qdc.cpp file:
this->indexCount = ENC_GetPositionValue(this->encBase);
But there is no indexCount hal pin...
In the fact, we don't need receive index pulse at component side, because change of indexCount means index was betwen last and present data transmision.
So we can update indexCount at every encoder's index edge, but use them only if hal index_enable pin is true. (look at my code).

I tried use raw_count and index pins connected to PRUencoder module. Sometimes it works, mostly not.
But even if it works, PRUencoder resets position to zero at received index, not at real index.
In my code, position is reset not to zero, but to
pos = (fb.raw_encoder - latched_enc) / pos_scale;
(raw_encoder may be not equal latched_enc)
So there is no delay.
In this case I not need PRUencoder, because I move pos and vel calculations to my component. 

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

More
20 Jun 2025 19:34 #330589 by andypugh

But this is very bad idea to send encoder's index pulse by ethernet.
Let's make calculations.
3000 rpm and 1 ms base_thread is 18 degrees accuracy - not acceptable.

This is actually fine, and is how all the other encoders work (Mesa, Pico, software) 

The counts are cleared on the index. 
At the beginning of the execution thread the motion controller gets the _current_ position, which includes all counts since the index.
These are used to calculate the actual position in space of the index. 
It isn't even time-critical, what the controller gets is the position in space of the index. It would still be perfectly accurate even if the motor did several turns between the index reset and the data getting to the PC. 
 

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

  • scotta
  • scotta's Avatar Topic Author
  • Offline
  • Platinum Member
  • Platinum Member
More
21 Jun 2025 01:00 #330608 by scotta
Hi tuxcnc,

Have a bit more of a look at the module code.

1. Index count is captured in an ISR.
2. When the next servo period runs the module, the index input is set in the data packet so LinuxCNC knows that the index was detected.
3. The index count captured in the ISR is stored in the data packet.

On the LinuxCNC side, if the index enable hal pin is set and the phase Z input (the index input) then the the index count is set with the encoder count, the count that was captured in the ISR.

The ISR latency is the only potential timing miss match.

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

More
21 Jun 2025 03:42 - 21 Jun 2025 09:23 #330609 by tuxcnc
Maybe I some don't know...
Maybe I do something wrong...
But :
root@HP-15:/temp/temppp# ls -n remora*
-rw-r--r-- 1 0 0 24206 2024-12-19  remora-eth-3.0.c
-rw-r--r-- 1 0 0   894 2024-12-19  remora-eth-3.0.h
root@HP-15:/temp/temppp# md5sum remora*
b447865ec7d51854e3baae2c9649fc65  remora-eth-3.0.c
4d64b37ed9177dbdb67f64479a2985f5  remora-eth-3.0.h
root@HP-15:/temp/temppp# cat remora-eth-3.0.c | grep comp_id,
            comp_id, "%s.enable", prefix);
            comp_id, "%s.reset", prefix);
            comp_id, "%s.status", prefix);
                    comp_id, "%s.joint.%01d.pos-cmd", prefix, n);
                    comp_id, "%s.joint.%01d.vel-cmd", prefix, n);
                comp_id, "%s.joint.%01d.enable", prefix, n);
                comp_id, "%s.joint.%01d.pos-cmd", prefix, n);
                    comp_id, "%s.joint.%01d.vel-cmd", prefix, n);
                comp_id, "%s.joint.%01d.freq-cmd", prefix, n);
                comp_id, "%s.joint.%01d.pos-fb", prefix, n);
                comp_id, "%s.joint.%01d.scale", prefix, n);
                comp_id, "%s.joint.%01d.counts", prefix, n);
                comp_id, "%s.joint.%01d.pgain", prefix, n);
                comp_id, "%s.joint.%01d.ff1gain", prefix, n);
                comp_id, "%s.joint.%01d.deadband", prefix, n);
                comp_id, "%s.joint.%01d.maxaccel", prefix, n);
                comp_id, "%s.SP.%01d", prefix, n);
                comp_id, "%s.PV.%01d", prefix, n);
                comp_id, "%s.output.%02d", prefix, n);
                comp_id, "%s.input.%02d", prefix, n);
                comp_id, "%s.input.%02d.not", prefix, n);
                comp_id, "%s.NVMPGinput.%01d", prefix, n);
root@HP-15:/temp/temppp#
Is the PV raw count?
Is the index some input?
Where is position captured at index ?
Last edit: 21 Jun 2025 09:23 by tuxcnc. Reason: typos

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

  • scotta
  • scotta's Avatar Topic Author
  • Offline
  • Platinum Member
  • Platinum Member
More
21 Jun 2025 22:13 #330660 by scotta
Hi tuxcnc,

The PRUencoder component is used.

github.com/scottalford75/Remora/tree/mai...omponents/PRUencoder

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

More
21 Jun 2025 22:24 #330662 by cakeslob
Hey tux, Im getting the feeling of deja vu. Didnt we go over this a few years ago? Its been explained both times, that this is how LINUXCNC does the threading, not just remora. You are also not the only person doing threading with the EC500, Remora, or LinuxCNC. Are you sure you have the encoders setup correctly? Ive seen you mention several times you dont know how to set up the index. Maybe it would be helpful to post your ini/hal/config.txt? 

You shouldnt take it personally if we dont understand the issue you are having. If you dont like the way we conduct our selves, you are free to fork the project. This way, you do not need to feel like you are at the mercy of the author. No one needs to throw a tantrum, you can point out the issue, and if it is not addressed in a way acceptable to you, make a fork, and correct the issue and move on with your day. We appreciate your input on the issue, but dont take it personally if the issue isnt addressed in the way you want.

But you appear to be unsatisfied with every single one of the remora projects, and every opensource cnc project in general. Maybe the Remora project needs to learn by example. Feel free to fork the projects and show us how it should be managed.

I look forward to testing out your new project thought. All the best, and I assume the documentation and instructions will clear and not misleading. I have faith you will retain interest for more than 1 month before moving on.

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

More
22 Jun 2025 05:51 - 22 Jun 2025 06:48 #330673 by tuxcnc
I feel like when I calling Microsoft customer's support...
"We dont know what is your problem, but it works with us..."

I know how Linuxcnc does the threading, and know why it is acceptable with LPT and not acceptable with devices using ethernet link.
LPT uses base_thread, ethernet uses servo_thread, so LPT can be ten times faster.

I told you few posts ago, the servo_thread=1000000 (1 ms period) can make delay that can produce 18 degrees positon error at spindle rotates 3000 rpm.
3000 rpm => 50 rps => 20 ms per revolution.
It is mathematics, everyone can make this calculations.

The solution is not send the extended index in hope the Linuxcnc see it, and resets position to zero when received it.
The solution is send raw_count latched at every real encoder's index edge.
We can restore encoder's index (if we need) from (old != new) at the component.
And we can reset position not to zero, but to real position captured at index edge.

We can be confused, because we use "index" word for different meanings (encoder's output, program variable, hal pin) but we can not change this.

Detailed explanation:
Let's assume the encoder's index edge occurs at 1000 raw_counts.
Time goes, counter counts A/B signals.
The component requests data.
At this moment raw_counts is 1050.
We send both values, counted and latched.
The component knows, the index was 50 counts ago and sets position to 50/scale not to zero. (of course only when hal index_enable pin is set)

What don't you understand?

I didn't want attached my project as offtopic, but I see I must.

File Attachment:

File Name: SpindleETHv4.tar
File Size:50 KB
Attachments:
Last edit: 22 Jun 2025 06:48 by tuxcnc. Reason: typos
The following user(s) said Thank You: cakeslob

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

More
23 Jun 2025 19:27 #330767 by Murphy
@scotta, I just tested the 3.1.4 unfortunately it's still the same no change. Spindle dips to nearly zero while in CSS

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

Time to create page: 0.223 seconds
Powered by Kunena Forum