Remora - ethernet NVEM cnc board

hello scott, could you tell me how exactly runModule() works

void Module::runModule()
{
++this->counter;

if (this->counter >= this->updateCount)
{
this->slowUpdate();
this->counter = 0;
}

this->update();
}


void Module::runModulePost()
{
this->updatePost();
}

What value would be sent to these two variables

Module::Module(int32_t threadFreq, int32_t slowUpdateFreq) :

Module::Module is the base class for all modules that allows a standard interface for the threads (vectors that are iterated over in the ISR) to execute each loaded module.

The module is registered in the thread in prdThread,cpp

And runModule() is called then the thread is run by the ISR.

runModule() then calls slowUpdate() and Update() that is defined in each module.

Hope that helps.

mrbubble wrote:

scotta wrote:

Just created the dev branch.

https:/github.com/scottalford75/Remora-RT1052/tree/dev
Found this when down the rabbit hole of getting Remora SKR running on a cheap fan less Linux PC SoC
There's a ton of potential with this rt1052, I'm thinking servos..

— Four FlexPWMs
– Up to 8 individual PWM channels for each
– 16-bit resolution PWM suitable for Motor Control applications
— Four Quadrature Encoder/Decoders

Your quick start instructions for getting the toolchain setup are stellar. Thank you so much!
Cannot wait for my CIMSS device to arrive.

Yes, it's a super feature rich MCU that you would think the Digital Dream designers would have sat back and though how best to use them. I've been working to get the VSD analogue output up and running and thought it would be as simple as setting up the pin PWM. Would you believe that the VSD pin is not PWM or flexPWM capable. It's not even an output on the XBAR so we cannot route to the pin either... back to software PWM then.

 

What would be the logic to call " slowUpdate()?

Modules like RCServo use the slowUpdate(). A module can only be registered in one thread but sometimes we would like the functionality of both the servo thread and base thread. Servo thread (slow) to update the position set-point and the Base thread (fast) to update counters and drive outputs.

There are two constructors for the Module base class, one for a standard module and one for "slow" module. The second constructor determines the updateCount that will determine how often the slowUpdate() method is called.

Scotta, hope you don't mind but I have a few of questions?

a) are you intending to develop the STM32F407 version of Remora code further or do you consider it complete? I ask because this version of the code does not support encoders, servos, etc.

b) what is the benefit of allowing configuration of the functional blocks for the controllers or put another way, given the inputs/outputs have fixed functions based on the hardware design would it not have been easier just create a monolithic chunk of firmware.

c) It looks like you based the code of the STM32 LwIP_IAP example with the IAP code included in your release. Have you tried it and is it possible to flash new firmware using tftp?


You probably don't care but I believe all six stepper channels of the EC300/NEVM could easily be driven via the STM32 timers. Two of the channels have their timer outputs attached to the direction pins rather than the pulse pins but that could easily be resolved by simply swapping the labels/wiring on those ports.

Hi, happy to answer

a) The STM32F407 for the old EC500 is basically complete. Only two pins are available for the QEI hardware module. Software encoder module could be ported over from the Mbed version of Remora if really needed. The switching speed of the optos would need to be checked.

b) The STM version for the NVEM and EC500 was a simple port of the exiting Remora firmware developed for 3D printer controller boards, hence the JSON config file. The RT1052 version is now a simple static config.

c) No have not gotten into other means of flashing the firmware, busy getting the RT1052 version working.

Regarding your last point, earlier in the thread is discussion and work done to use timer driven DMA transfers to step and direction pins. Work stopped on this with the release (and support needed) for the RT1052 version of the board.

very smart on your part, the use of the vector to interact with the modules, I'm studying about.

The end of year craziness is coming to an end and a few hours back in the workshop to work on Remora for the RT1052. Today I've pushed to the dev branch of the repo the latest work to get the VSD PWM -> 0-10V working. I did have this running a while ago with a software PWM version but now this is all done in hardware PWM using the Quad Timer channel on pin D7. I originally thought that the VSD pin was not hardware capable until I started work just to find out that I have traced back to the wrong pin. 

Now to move onto getting the NVMPG serial comms up and running.

Sorry to chime in here, I just found the NVMPG mentioned here. It looks like a nice affordable controller to me, but unfortunately I'm unable to find information about the serial comm protocol. Do you have any documentation on that?