Remora - ethernet NVEM / EC300 / EC500 cnc board

Hi there.

I am trying to setup a new computer with Linuxcnc connecting to a previously setup EC500

When I download the Remora files & try to do a halcompile I get an error compiling.

So I have done ...
wget github.com/scottalford75/Remora/blob/fea...ora-eth/remora-eth.c
wget github.com/scottalford75/Remora/blob/fea...ora-eth/remora-eth.h
sudo halcompile --install remora-eth.c

Here is an attachment with the output (as much as I could capture)
This is a reasonably fresh install of 2.8 upgraded to 2.10 using buildbot.

Any ideas on how to solve this would be appreciated.

Thanks
Alex


 

Hi,

For the EC500 you will need the latest version of the component.

github.com/scottalford75/Remora-NVEM/tre...Components/Remora-nv

remora-eth was an early testing version when I was playing with the W5500.

I have tried that but am still getting (a rather unintuitive) error.

I have tried this ....
wget github.com/scottalford75/Remora-NVEM/blo...emora-nv/remora-nv.c
wget github.com/scottalford75/Remora-NVEM/blo...emora-nv/remora-nv.h
sudo halcompile --install remora-nv.c

And am now getting the error in the attachment.
Is there anything I need to de to make a clean environment?

Alex
 

frayja2002 wrote:

I have tried that but am still getting (a rather unintuitive) error.

I have tried this ....
wget github.com/scottalford75/Remora-NVEM/blo...emora-nv/remora-nv.c
wget github.com/scottalford75/Remora-NVEM/blo...emora-nv/remora-nv.h
sudo halcompile --install remora-nv.c
 

The explanation is very simple.
You don't download source files, but html files.
Go to github page, open file preview in your browser, and look for "download raw file" button, then use it.

yep you are right.
I should have opened up the files & checked them.
Sorry to have cluttered up the thread with such a dumb question.

ALex

scotta wrote:

I assume that the proper config is :

{
    "Thread": "Base",
    "Type": "Encoder",
        "Comment":            "Encoder A-IN9 B-IN10",
        "PV":            0,
        "ChA Pin":            "P3_19",
        "ChB Pin":            "P3_20",
    "Data Bit":          11,
        "Index Pin":          "P3_21",
    }
    
And :

# Initialize the encoder (spindle)
    loadrt PRUencoder names=encoder.1
    addf PRUencoder.capture-position servo-thread
    setp encoder.1.position-scale 200.000000 #6
# connect the hal encoder to linuxcnc
    net encoder-count remora.PV.0 encoder.1.raw_count
    net encoder-phaseZ remora.input.11 encoder.1.phase-Z
    
I assume that the remora.input.11 in this config is not EC500 IN9 input, but output from your procedure for lengthening index pulse.
Am I right ?

For comparison I tested the config without "Index Pin" declared (PRUencoder uses direct IN9 input signal as index in this case).

I made tool for tests.
It is ATtiny 44A with ULN2803.
ATtiny because I have (I'm using it when I need Arduino IDE, but hardware needs 3,3V levels).
ULN2803 for convert ATtiny outputs to OC (open collector).
The code is very low quality and depends on system clock, but works.
On Attiny 44A with internal 8 MHz clock it gives ~5,5 kHz phase signal and ~1,4 ms index pulse.
The code is :
 
#define start_pin   10
#define encA_pin    2
#define encB_pin    3
#define encZ_pin    4
#define idxlen      25
#define steplen     40
bool old = 1;
bool now = 1;
bool enc_A[4] = {0,0,1,1};
bool enc_B[4] = {0,1,1,0};



void setup() {
  pinMode(start_pin, INPUT_PULLUP);
  pinMode(encA_pin, OUTPUT);
  pinMode(encB_pin, OUTPUT);
  pinMode(encZ_pin, OUTPUT);
  digitalWrite(encA_pin, 0);
  digitalWrite(encB_pin, 0);
  digitalWrite(encZ_pin, 0);
}

void loop() {
  now = digitalRead(start_pin);
  if ((now == 0) && (old == 1)) {
    digitalWrite(encZ_pin, 1);
    for (int x=0; x<200; x++){
      digitalWrite(encA_pin, enc_A[(x & 3)]);
      digitalWrite(encB_pin, enc_B[(x & 3)]);
      delayMicroseconds(steplen);
      if (x == idxlen) { digitalWrite(encZ_pin, 0); }
    }
    delay(1000);
  }
  old = now;
  }
 
On falling edge of the start_pin immediately and together starts pulses on A, B and Z outputs.
The count of states is 200, so if encoder.1.position-scale is 200 too, the encoder.1.position will be increase or decrease by one on each falling edge of start_pin input.
The delay(1000) prevent to start next cycle if not pass 1 second from previous.
But if you set encoder.1.index-enable to TRUE and start the tool, some pulses are lost, because start together with index, but PRUencoder counts only incoming after counter reset.
So you get for example 0.896 instead of 1.000. The difference is wanted error value.
My English is poor, but I hope you understand.

The test results are bad.
First, the maximum of phase signal frequency not exceed 5 kHz. (Five not fifty...)
I don't know why, it may be hardware problem in my tool or EC500 input optocoupler, but if frequency are higher the counter lost some pulses (position not changes exactly by one).
The second problem must be a bug in your code.
The error seems be lower than with PRUencoder uses direct IN9 input signal, but some index pulses are lost, let's say the spindle must do many turns before synchronize...
The amount of lost pulses are 50% or more, so it is very bad...

I thought I will increase servo period and coefficient of 3 in line 63 of encoder.cpp file, but I can't compile your newest code ( github.com/scottalford75/Remora-RT1052-cpp/issues/1 ).

I hope the information above will help.
 

Hi, thanks for the notification of the flash size issue. Please see my comment in the repo for resolution.

The Remora code is based on the the LinuxCNC encoder module, so I think the logic has been well tested.

As you've noted, the index pulse and encoder count (on index) is sent to LinuxCNC for 3 servo periods.

When homing on index, the intent of the index input, the speed is low so there is unlikely to be any change of count during those 3 servo periods.

We need to understand the capabilities of the optos as you said to understand what the max frequency for reliable counting could be.

The encoder module is running in the base thread, so the index pulse will need to be able to be seen at that scan rate.

 

scotta wrote:

[code]We need to understand the capabilities of the optos as you said to understand what the max frequency for reliable counting could be.

[/code]
 

There are ACPL-247 (or Chinese clones) optocouplers on inputs. These can 100 kHz I suppose, but there are some resistors and capacitors, usually added for noise resistance. Maybe the Chinaman exaggerated with their values, maybe we need remove some ...

I'm sorry, I can't do more tests in next two weeks - my EC500 board is dead.
Maybe something bad happened when programming, or maybe it is a factory defect, but it is dead and I no hope for it's resurrection ...

hello everyone here, I have been active for several days following the latest news about ethernet rt1052 delay and I see a lot of progress regarding the C++ version of the project and the IAP configuration, Scott, you have worked hard and a great project, my respects !!!
I have read before that tuxcnc has had unexpected problems with its EC500 board, I was doing some tests with an EC300 a while ago and in one of the times that I uploaded the firmware the board stopped working, at that moment I had incorporated the firmware module encoder to the static version of the firmware, just when everything started to go smoothly after some tests in a firmware load the board just stopped working this was with CMSIS-DAP and OpenOCD from Ubuntu, if there is any idea about it, Is it a problem very similar to tuxcnc?
I have a 24V encoder and an EC500 arrived a few days ago, so as soon as I can I'll start trying again, there's no other way.

rbobey1989 wrote:

hello everyone here, I have been active for several days following the latest news about ethernet rt1052 delay and I see a lot of progress regarding the C++ version of the project and the IAP configuration, Scott, you have worked hard and a great project, my respects !!!
I have read before that tuxcnc has had unexpected problems with its EC500 board, I was doing some tests with an EC300 a while ago and in one of the times that I uploaded the firmware the board stopped working, at that moment I had incorporated the firmware module encoder to the static version of the firmware, just when everything started to go smoothly after some tests in a firmware load the board just stopped working this was with CMSIS-DAP and OpenOCD from Ubuntu, if there is any idea about it, Is it a problem very similar to tuxcnc?
I have a 24V encoder and an EC500 arrived a few days ago, so as soon as I can I'll start trying again, there's no other way.

Hmm, strange that a firmware upload would brick a board. I suspect that the it's not booting correctly. I had that issue early on when learning how to connect and program the EC300. The first version of the board I had with the RT1052. The good thing with the EC300 is that it has a boot button which you can use during power on. That may be worth a try.

Which encoder did you get? I'm tempted to get one as I've been looking at the hardware counting capabilities and it looks to be very flexible to pin assignment (if I can get my head around the xbar).