Remora - ethernet NVEM / EC300 / EC500 cnc board

Oh great thank you, is it possible to use the 5v encoders on the machine with the EC500 ? 

Hi Murphy, These two bits REV and PH1 of the CTRL register of the QDC module give us the behavior necessary to implement the behavior you need.
REV
Enable Reverse Direction Counting
Selects the direction of the count (how the quadrature signal is interpreted).
0 - Count normally
1 - Count in the reverse direction

PH1
Enable Signal Phase Count Mode
Bypass/use the quadrature decoder logic.
0 - Use the standard quadrature decoder, where PHASEA and PHASEB represent a two-phase
quadrature signal.
1 - Bypass the quadrature decoder. A positive transition of the PHASEA input generates a count signal.
The PHASEB input and the REV bit control the counter direction: If CTRL[REV] = 0, PHASEB = 0, then
count up If CTRL[REV] = 1, PHASEB = 1, then count up If CTRL[REV] = 0, PHASEB = 1, then count
down If CTRL[REV] = 1, PHASEB = 0, then count down

Regarding the input voltage levels, good and bad news hehe, currently for a quick 5V connection for encoders you only have two inputs WHA and WHB, you would have to do a little DIY to connect these pins because they are in the MPG connector, no I know if you use MPG with this version you are sacrificing it, the other thing would be to incorporate some level shifters, driver transistors, optos, etc., to achieve the coupling from 5V to 24V and use the pins that are mentioned in this previous Scott publication in which we were discussing which pins can be used on the EC300 and EC500 boards.

frayja2002 wrote:

Here is the machine with the exact same setting ( just a restart) running smoothly.
You can hear the sound difference.

Seems to be random.

youtube.com/shorts/0rLC4tKUu0I?feature=share

Edit-01

I have tried this on my Biessie machine which used Yaskawa driver servo motors & yes the speed is much increased & working better, but at random the direction of the axis changes. I think I saw mention of this earlier in the thread. I'm assuming it's related?!?

 

I'm very very suspicious that these random cases are due to how the DR_TOGGLE register is being used and in some cases the output pattern become inverted. The DR_TOGGLE register needs less computation to fill but if the reliability is not there then I'd rather move to using the DR register and spend more CPU time to generate the full step pattern, not just the step change locations. Most people are unlikely to have 6 axes running at 500khz at any one time so we'll still have enough CPU time to do the step buffer fill.

rbobey1989 wrote:

Hi Murphy, These two bits REV and PH1 of the CTRL register of the QDC module give us the behavior necessary to implement the behavior you need.
REV
Enable Reverse Direction Counting
Selects the direction of the count (how the quadrature signal is interpreted).
0 - Count normally
1 - Count in the reverse direction

PH1
Enable Signal Phase Count Mode
Bypass/use the quadrature decoder logic.
0 - Use the standard quadrature decoder, where PHASEA and PHASEB represent a two-phase
quadrature signal.
1 - Bypass the quadrature decoder. A positive transition of the PHASEA input generates a count signal.
The PHASEB input and the REV bit control the counter direction: If CTRL[REV] = 0, PHASEB = 0, then
count up If CTRL[REV] = 1, PHASEB = 1, then count up If CTRL[REV] = 0, PHASEB = 1, then count
down If CTRL[REV] = 1, PHASEB = 0, then count down

Regarding the input voltage levels, good and bad news hehe, currently for a quick 5V connection for encoders you only have two inputs WHA and WHB, you would have to do a little DIY to connect these pins because they are in the MPG connector, no I know if you use MPG with this version you are sacrificing it, the other thing would be to incorporate some level shifters, driver transistors, optos, etc., to achieve the coupling from 5V to 24V and use the pins that are mentioned in this previous Scott publication in which we were discussing which pins can be used on the EC300 and EC500 boards.

 

​​​​​​ great thank you very much , I'll have a play around with this in a couple of days. I tried to use a opto originally but the 5v encoder pulse was to weak to Tigger it even though it's rated at 5v
 

Had a quick look at the reference manual on 3129, can see the PH1 and Rev. For the Tool changer. It never counts backwards. 24v is sent to the tool changer and moves the turret forward until selected tool is reached. It passes that pocket slightly, and 12v is applied and it reverses,  latching into the pocket.  

A fellow on YouTube "the feral engineer has it working with a Mesa and ladder logic. Some counters and timers etc. 

I have the 5v turret tool position signal on input 3 and index on input 4.
Input 1 and 2 are the 24v Prox sensor. Pulses every stepper rotation. For homing. Works perfect.

When driving the turret you can see the LEDs lighting on the optocoupler and on the EC500 but they are a lot dimmer than input 1 and 2. The inputs for the turret are not registering in hal. Am I right in thinking the 5v input isn't enough to drive the optocouplers? Even it says it will work with 3.3v and 5v.

 

 
I'm very very suspicious that these random cases are due to how the DR_TOGGLE register is being used and in some cases the output pattern become inverted. The DR_TOGGLE register needs less computation to fill but if the reliability is not there then I'd rather move to using the DR register and spend more CPU time to generate the full step pattern, not just the step change locations. Most people are unlikely to have 6 axes running at 500khz at any one time so we'll still have enough CPU time to do the step buffer fill.

From what I could observe and this is just my experience, the directional changes happen only between restarts of linuxcnc . And in my case it happened only for one of the motors of the tandem y axis where one of the motors will start to spin ccw when they should both spin cw. This occurs withbought power cycling the board. For me, the directional switch never happened during the same session of linuxcnc.

Couple that with the fact that outputs of joints will jump from one slot of the board to another if the machine configuration is modified in the ini file. Ex going from XYZ to XYYZ . Could this problem be on the linuxcnc side and not on  the board firmware side?

I could not find a reliable sequence of steps to reproduce the directional change other than observing that it happens at random between restarts of LCNC.

Did anyone experienced directional switches during the same session of linuxcnc operation using the dma branch?

Murphy wrote:

I have the 5v turret tool position signal on input 3 and index on input 4.
Input 1 and 2 are the 24v Prox sensor. Pulses every stepper rotation. For homing. Works perfect.

When driving the turret you can see the LEDs lighting on the optocoupler and on the EC500 but they are a lot dimmer than input 1 and 2. The inputs for the turret are not registering in hal. Am I right in thinking the 5v input isn't enough to drive the optocouplers? Even it says it will work with 3.3v and 5v.

Have you tried displaying all the input pins in the hal window? For example, for me input7 on the board corresponds to input9 in hal. Perhaps you are just reading the wrong pin in hal. From what was explained to me, the pin numbering is governed  in the .txt configuration file that is loaded on the board so, in my case i should modify that in order to have an exact numbering corespondence.

I did. When I ground the pin straight to ground the led on the EC500 gets brighter and registers in hal

After A LOT of trial and error, thanks to the absolute hero GeramyL I was able to get LinuxCNC running with the NVEM board. Turns out the fault was that I wrote the nvem-basic-config.txt to the board instead of the nvem-full-config.txt. I'm still not sure why it didn't work or why there is a basic config if there is no reason to not use the full config. Either way I'm super happy to finally be at the point where I get to learn how LinuxCNC works!

I've set up tandem Y and limit switches, and now I'm trying to get the spindle configured. The issue that I'm facing is that the analog out pin, VSO, is normally high, so 10 v with no spindle speed request or when LinuxCNC is off. When requesting half speed the voltage goes down to 5 v, and at full speed 0 v. So completely reverse of what it should be.
Is there an easy fix for this? I did some testing with lincurve, but haven't been able to figure out how to invert the signal.

Edit: Never mind! I figured out how to map it correctly using lincurve =)