Remora - ethernet NVEM / EC300 / EC500 cnc board

I'm still researching Remora, you never stop learning, as it says in the remora documentation Index signal is shared with the digital input pin, that is, the databit on the pin where we physically connect index pin must be set in the QDC configuration as well: or it would look like this:

{
"Thread": "Servo",
"Type": "QDC",
"Comment": "QDC Encoder A-IN11 B-IN12 I-IN14",
"PV": 1,
"Data Bit": 17.
"ChA Pin": "P4_00",
"ChB Pin": "P3_23",
"Index Pin": "P4_15",
"ENC No": 2
},

since in firmware *(this->ptrData) points to the inputs and this->mask= 1 << this->bitNumber
set the index input *(this->ptrData) |= this->mask;
clear the index input *(this->ptrData) &= ~this->mask;

everything working now although with some modifications, I was looking at the functions included in the QDC driver fsl_enc.c:

uint32_t ENC_GetPositionValue(ENC_Type *base)
{
uint32_t ret32;

ret32 = base->UPOS; /* Get upper 16 bits and make a snapshot. */
ret32 <<= 16U;
ret32 |= base->LPOSH; /* Get lower 16 bits from hold register. */

return ret32;
}

and,

uint32_t ENC_GetHoldPositionValue(ENC_Type *base)
{
uint32_t ret32;

ret32 = base->UPOSH; /* Get upper 16 bits and make a snapshot. */
ret32 <<= 16U;
ret32 |= base->LPOSH; /* Get lower 16 bits from hold register. */

return ret32;
}

In the ENC_GetHoldPositionValue function, the LPOSH is already obtained. I don't know the intention of this, but when I read the ENC_GetHoldPositionValue I do not have a correct reading. According to the reference manual, when the POS, POSD, REV registers are read, a snapshot is made of the corresponding hold registers. I have carried out tests modifying the fsl_enc.c reading LPOS that is:

uint32_t uint32_t ENC_GetHoldPositionValue(ENC_Type *base)
{
uint32_t ret32;

ret32 = base->UPOS; /* Get upper 16 bits and make a snapshot. */
ret32 <<= 16U;
ret32 |= base->LPOS; /* Get lower 16 bits and make a snapshot. */

return ret32;
}

In order to then pass the reading of ENC_GetHoldPositionValue() But I keep getting the wrong reading, where I get a moderately correct count is by using the ENC_GetPositionValue() function at the beginning of the QDC::Update function, I say moderately because the values do not match 100%. sim_encoder.raw_counts values with what I get through remora.PV.1, difference of 4 counts, if I can say anything it is that the dupont cables must help a lot.

Again, thanks for the work on the hardware encoder implementation. I've just been reviewing the STM32 version and there are a few things that we should consider for the RT1052 version.

1. The QEI version runs the module in the Base thread so that we have absolutely the latest encoder count when a PRU read request is received.

2. The index is an interrupt pin with the ISR getting the encode count, not waiting for the next thread period to run.

3. By having the index on it's own interrupt, not the QDC module index input, the board could support a total of 4 hardware encoders.. correct.

The qeiDriver, has the ISR stuff.

github.com/scottalford75/Remora/blob/mai...rs/qei/qeiDriver.cpp

Sincerely thanks for the response, sometimes ideas and experience are worth more than the implementation itself, a good approach is to change the QDC module to the base thread, I have not tried it in the base thread, in fact I saw that in some firmware versions If you used it in one thread or another, in the base thread we would obtain a better sampling rate. I thought about the issue of interruption due to the index event this afternoon. In fact, I'm already working on it. There is an example in the SDK.

What I do not agree with is that we do not have pins to use the 4 hardware encoders at the same time, we only have 6 pins that we can connect to the encoders through XBARA1, at least I did not find more, the encoders can be used interchangeably

Is there any feasibility/possibility of implementing DMAstepgen in the Remora branch with Mbed OS?

Hello Scott, I have added the index interruption and registered the module in the base thread, I have also added the instance for the ENC4 although without physical pins mmmmm, it seems to work well, now looking at the digital filter, it would be the last addition, the latest changes in my repository , greetings

Thanks. I've had a look at the pad mapping today. We might have some extra inputs on the XBAR

Pad A5: GPIO4_IO16 Available on the NVEM and EC300 as YIN

Pad C3: GPIO3_IO22 Available as INDEX on EC300 and SRO on EC500

Pad H2: GPIO3_IO16 Available as WHA on EC300 & EC500

Pad J2: GPIO3_IO17 Available as WHB on EC300 & EC500

The last two make sense from a design perspective, they are the MPG encoder inputs. So we might be able to get 4 encoders, 3 as 24v PNP and the 4th as 5V.

Is my interpretation correct? XBAR is all new to me.

Hi Scott, you have done your pin count correctly and yes your interpretation is correct, I had already looked at these pins but I always thought about using the MPG (although not having MPG is not critical, it helps a lot), it is always a good option to give the possibility of one more encoder, it would be easy to add the decoding for those pins to the XBARA1 at this point of development of the QDC module, I will add it soon, don't worry.
I don't know if I was misunderstood before with the PNP and NPN encoder outputs, maybe I made a lot of fuss hehe, the EC500 inputs are designed to connect open collector NPN outputs, that is, they only give the low logic level, what I meant in one of the previous publications is that the encoder with index that I have is PNP and I had to juggle with pulldown resistors to be able to read something, although for tests with sim-encoder it works great.

Changing the topic, now comes the interesting thing where many here can help is in the digital filter that the QDC module has, honestly about digital filters the basics of the basics mmmmmmm, there are three parameters that must be configured in the registry, they are supposedly explained in page 3131 of the reference manual. If anyone can shed light on this I appreciate it.

How are you tracing your pins out? I'm not sure if you saw my comment about and i'll use the common names for these pins, XP-, XD-, YP-, YD-, ZP-, ZD-, AP-, AD-, BP-, and BD- that these pins may not be setup correctly, I have had to wire all my negative lines on the stepper drivers straight to common instead of using these pins. It seems these negative pins are flipping from positive to negative and all kinds of crazy thing, that I could tell. I could be wrong but I don't think so. Do you have these pins mapped out? Maybe we can sink these to ground, make them a input. Also you might be able to use these pins also for other stuff as well, whats the specification on the actual chip thats connected to these pins, are they input, output, or both?

Hey, Scott (or any volunteer)!

Have you had the time to look at my config files that are causing the following errors? I use the remora-nvem-basic config from github.com/scottalford75/Remora-NVEM/tree/main/LinuxCNC , also attached to this message.