Advanced Search

alright now, any questions?

aDm1N wrote:

I started from scratch with the standard examples. I made some adjustments, and now Remora Input 4 is responding. However, this only happens when the emergency shutdown is disabled in the GUI. So, Remora probably only starts working after that.

that makes sense.
refer to tuxcnc example

I havent tested it, but this looks like what you need to do. you need to modify the portion of your halfile that already references it

DarkPhoinix wrote:

I have recreated the problem with the function generator. Now I am sure the problem lies in the configuration, or so I believe. For now, I would like to know which parameters I need to set to have the same parameters for frequency and pulse times in the hal and ini files (like pulse 1,000,000ns frequency 988Hz). Thank you again for your patience!

refer to the previous posts. replace the stepgen in your config.txt with the DMA stepgen. Make sure the step and direction pins are the NVEM one. The step time and space parts are what you need to configure. I dont know the units. start at 1 and 1 and go up from there.

I need hardware suggestions.  There seems to be a gap in my knowledge, and in my research.

I just got a new CNC router, and it came with a Grbl-based controller.  I always used LinuxCNC in the past on my DIY machine, and I can already tell that I'll probably be happier if I switch to LinuxCNC on the new one.

The most recent incarnation of the old machine was driven by a Raspberry Pi and a Mesa ethernet card.  The Mesa was connected almost directly to the limit and estop switches, and the step/dir lines went to a quad stepper driver board I got from Sparkfun a long long time ago.  The wiring was a horrible rat's nest of jumpers running between pin connectors glued upside down to a plank.  (I'm not exaggerating.) And I don't want to use the Sparkfun board again, for various reasons.

At some point I'm going to want to use the Mesa card with the new machine.  But what I'm picturing, that I don't have, is the "interface" board.  It needs to take 24V power, and have 3 or 4 of those little 16 bit stepper driver modules.  And it needs to have a bunch of screw terminal strips, set up to logically simplify the 6 or 7 pairs going to switches, the 3 or 4 connections to the motors, and all of the interconnect to the Mesa.  Basically what I want is an XYZ CNC router breakout board, with drivers.

But all I can find is complete controllers:  all of what I described, hardwired to an ATMega328, or ESP32.  Or, all of what I described, in the form of an Arduino hat.  Better, but still not very Mesa-friendly.

Can anyone point to the product I'm looking for?  Or tell me (nicely what I should be looking for instead?
 

 

 

Estop is the same way. With Estop, we are connecting a remora.input to LinuxCNC estop. Estop is a very subjective thing, and varies between setups. They can be complicated and require more hardware. Murphy has posted a simple example, and tux from a few pages back has posted a more detailed one.

Notice how the inputs are different on each of their different estops, which makes no difference because we are connecting remora.input.whatever to linuxcnc estop.

Tuxcnc is more complicated, He is using LinuxCNC components (not remora) to configure the estop logic. it includes a latching component, I assume he has one of those red buttons. Im not as knowledgeable with all the estop logic, as I live dangerously. The estop loop is a function of LinuxCNC and you need to connect it to remora in a way that suits your setup.

Sorry about that, I'll take a look tomorrow.

We have 3 phase power in houses, always, rated at 3x380V +-10% and can pull 16A at home from any plug, 32A in workshops/garages.
Lately the local provider started complaining if we pull over 15KW over long duration's, i do not blame them, we have 100A at our disposal.
To spite Americans (since i still refuse to go there despite being granted a Green Card 17 years ago), we can charge a Tesla at home with 22KW on any socket around the house, 60KW if we push it!
And that is with no permissions or requests or installing superchargers!

grijalvap wrote:

I understend what you mean but I want to keep the temporary tools because they are in the GCODE file, the operator don't has to select.
 

If you set the cut parameters up correctly (eg replicating sheetcam toolsets in qtplasmac by importing the Sheetcam tools), the user still won't need to select anything. Instead, Sheetcam will pass the tool number to QTplasmac in the gcode and it will retrieve the corrrect settings. Keep sheetcam the master of toolsets and update QTplasmac if you change settings.
 

 

here is a before and after

 


observe both configs. they are mostly the same, but some pins are different.

Pgain and ff1 and deadband are parts of the remora stepgen and used to tune motor control/feedback. feedback control has nothing to do with encoders or input from the motor. it is an internal math shit connected to the stepgen to tune motor position control like you would a servo.

regular stepgen and DMA stepgen have no difference in LinuxCNC. The same concept as inputs applies to the stepgen/dma stepgen. In the Config.txt you tell the MCU that pin P1_22 and P1_17 is step and direction of joint 0, which is remora.joint.0 which is connected to LinuxCNC joint.0

The DMA stepgen is a faster hardware based stepgen and requires dedicated hardware pins. LinuxCNC does not know if you are using DMA stepgen or regular stepgen and it does not care.

Looking at the EC500 DMA stepgen config, we can apply the same concept to the NVEM config.txt The config.txt for your specific board, and is just a way to tell the remora what pins do what. The default stepgen is regular stepgen because it is less to tune. If you want to change your stepgen to DMA stepgen, lets compare the config.txt DMA stepgen and apply it to the NVEM config.

 

If there are no hardware conflictions (there arent in this case) we can go about changing the stepgen to DMA stepgen. In this case the pins are the same for both boards. so replace your entire stepgen with the DMA stepgen and make sure the pins match the pins on your board

 

The config.txt file tells the MCU which pin is going to do what. so Pin P4_20, the imxrt1052 MCU pin, is assigned the title of remora input 06 . when pin P4_20 is triggered, the MCU tells remora that remora.input.06 is triggered.
Not to confuse things and its hardware restrictive, but you can make "remora input 06" to be whatever pin you want it to be, it doesnt matter what pin is input 5 or 6, but it has to match up.

The remora.hal file connects remora pin remora.input.06 to LinuxCNC pin joint.0.home-sw-in (this is the x home switch) So when pin P4_21 is triggers, it tells remora that remora.input.06 is triggers, which triggers LinuxCNC joint.0.home is triggered (x axis homing pin)

the remora.hal and LinuxCNC do not know if you have an NVEM or an EC300 they do not need to know and they do not care.

spincycle wrote:

I assume the procedure is similar for newer drives if running analog?

Yes.

spincycle wrote:

I would tune the velocity/torque in the drive software, then tune position through Linuxcnc.

Yes.

spincycle wrote:

It looks like a few of the modern servo drives I've looked at have encoder outputs. Those will just run back into a Mesa card like the 7I97?

Yes.
3 for 3, nice!
New drives can also be controlled by step/dir and also have encoder outputs, and those can again be used in LinuxCNC.
And there are several boards from Mesa that can be used, not just 7i97, a lot of combos there so when you are ready to order stuff, ask here first as we have the Mesa Master with us here, always, in the form of PCW.

"why you take some files from this path?"

If that question was asked of me, it took me a few to figure out what you might of been referring to. If it was this post here - www.forum.linuxcnc.org/18-computer/44828...rd?start=2180#327765 - then that is my fault completly as I was at the wrong place when I copied the link. My bad. Just went back and edited it. Looks like the difference is in the DMA version there is an additional line in the motor config -

setp remora.joint.1.pgain [JOINT_1]PGAIN

- that is not in the basic and not what I am currently using. I believe you said it, it's confusing, and yes, it would seam I have fallen head first into that confusion.

Bad Spyderbreath for adding more mess to the pile.

Alright its starting to look like the inmates are running the asylum. Everyone just hold on for a moment, breath in and out, and cool our heads. I know english or linuxcnc isnt everyones first language, but it looks like everyone is working off each others confusion, and you guys are spiraling out. I think there are some core concepts we arent all understanding completely. Its clear that you guys are smart people, so lets hold on for a moment and regroup, and always read the manual. If you atre getting frustrated, just start from page one and read. If there are things getting lost in translation on the documents, letting us know would be great, and we can change some of the wording. I know the docs arent perfect, but the core concepts are the same for the whole of remora.


Also, if its a remora specific question, it is best to ask in the thread. remora isnt really a big wide linuxcnc thing, it makes it harder to find your thread.

cakeslob wrote:

if it is stepper timing related you need to load the DMA stepgen config and adjust your step timing accordingly

I don't understand well,
I have to load all from:
github.com/scottalford75/Remora-RT1052-c...CNC/remora-ec500-DMA
and upload this to NVEM:
github.com/scottalford75/Remora-RT1052-c...ec500-rt1052-DMA.txt

Today I tried the updating progress and V16 was loaded.
Unfortunately the key matrix now doesn't seem to work anymore at all. I didn't have time to check with the scope but it looks like there is sth. general wrong now?
I checked with the meters in linuxcnc and the buttons that worked before aren't recognized anymore, as well as the buttons that didn't work before.
I am not sure if i measured that right but I checked with linuxcnc scope and I did not get a trigger on a changed keycode of the 7i73.
I counter checked to check general device integrity by checking analog values - they are still transmitted.