Advanced Search

hi Scotta
I wanted to compliment you on the work you have done and made available
to the LinuxCNC community.
I am excited about it and I bought an NVEM V5 to try to install the Remora firmware,
but when I opened the case I noticed that the chip is not an STM32F207 but the one in the photo


 


is it still compatible or did I buy the wrong card?

Thanks if you can give me some advice

P.S. sorry Scotta
I went a bit back with the posts and at 191 there is the answer to my question, thanks,
I'll move on....

Hello,

Now with the Mesa 7i96 there are more inputs and outputs to play with, compared to the old controller.

The machine has a (diy) mechanical spindle lock. It just slides on the wrench flats of the spindle.
The limit swicht for lock was previously connected to the E-stop in series, which is not the best way.
Now I connected the switch for the spindle lock to an input. in the hal file I connected that input to a pin called drive inhibit.

I cannot start the spindle drive when the switch is actuated and the spindle is locked. So far so good.

Now I tired to find some info how to get the Axis GUI to "disable the spindle buttons", maybe even some indicator on the GUI "spindle is locked" would be nice. And in ideal conditions I would not be able to run an automatic program.

If the spindle brake checkbox would be used it would be O.K. as well, but then I need to disable the automatic unchecking of the spindle brake, because the lock is manually operated.



 

Actually it's my issue for not checking the boot logs, the scripts setup the zram.service. Whether Raspberry OS uses zram is not related to our images, as we use Debian.....as of course you know.
The zram.service is part of the image builder, I've modified the process so the service shouldn't be enabled and later on install systemd-zram-generator and create a config that will use 1GB on a 4GB system, this can be modified if required.
As you can see zram tools are installed, this is whether or not systemd-zram-tools are installed.
The issue is because Bookworm uses systemd the package systemd-zram-generator is required, this is the missing piece of the puzzle. During the build the a different script is used to zram0 which fails.

As you can see from below zram0 is used for swap.
Without the mods I've describe above there is no swap. Whether it's need or not, but on a typical debian x86_64 install usually a 1GB swap partition is created.

As you can see it really doesn't affect the total free memory when it's not in use.And BTW it not caching memory nor mamory glands, but is creating a swap partition that is compressed in memory.

The simplest option is just to mark zram.service as masked and have no swap.

So at the moment I'm building an image with the mods.....and make sure I've done it right.

Rob

I have been stalled on this for quite some time. It's difficult work. Keep routing me on from time to time.

 
For the needs of my workshop, I built this plasma table.
The usable cutting area is 2790x1200mm, and it is equipped with a Hypertherm Powermax 105 SYNC, allowing cuts up to 32mm of steel.
I initially used the control unit from my CNC milling machine along with Mach3, but I was very limited in terms of available options.
 recently upgraded it to fully utilize all the possibilities of LinuxCNC/QtPlasmaC.

This is the V2, I will start the V3 soon with a complete rebuild and complete new mecanical design

Here are some photos:

 
 
 

Yesterday's job, 15mm steel:

 
 



 

I found the problem but "too late", it was this line into the .hal exemple file from QtPlasmaC that i'm using:

net plasmac:axis-position joint.2.pos-fb => plasmac.axis-z-position

Into this configuration file the Z axis is supposed to be on joint.2 but it was in my case on joint.3 (joint.2 was Y2).

Forgot to include the picture of the Z-axis so here you go. Also noticed that the y and z axis uses the ball screw mechanism while the x-axis uses rack and pinion mechanism.

Thanks for the advice, Tommy.
After reviewing all the information exchanged so far, do you think it's a good idea to start a new thread about retrofitting our Sbz 130 model?
Basic differences include:
1) all 4 motors are AC 3 Phase, with integrated 2-pole resolvers
2)no short X-axis
3) newer DARC system (drives motors) (manual attached)
4) possibly different mesa configuration (6i24 7i49 for resolves feedback and - 10V of analog control signals for motors?)
5) 2001 model
6) No pneumatic brakes are used for the x and y axis but we did notice some sort of pneumatic counterweight or brake for the z-axis (picture included)
7) In the picture you can see the 'DARC system' comprises of from right to left: supply module, that receives AC 380-415 3ph, then distributes through dc links (metal bars under the grey boxes)  L+ L- PE to the other drives (spindle, x, y,z), diagram attached as well.

Attached is a picture I got online of the control panel with all the connections intact of the same machine 2001 model. The next picture shows the internal connection on the top side of the spindle motor. The next picture shows the cables for the resolvers found in the DARC manual. A picture of the whole machine in its current condition is also attached. A table containing info about the motors used is also attached. A diagram of the DC linkage is also attached that distributes power to all drives sharing and originating from the supply module, all drives also have inbuilt inverters to send 3 ph AC to their respective motors.
This is a link containing the DARC manual and the electrical schematics for the SBZ 130 - we.tl/t-zhbMsN1qWM
 

Sorry, my research says zram is not installed by default on Raspberry OS. I don't see this is a Linuxcnc issue.
We've always said to use a 4 GB system and with that much ram, mamory caching is not required.

Maybe it is time to do some improvements and clean up. Like making PDOs of the scale and max-acceleration.
I wonder how much you have done to the code?
I can bring in those changes in the code, and push an update to github.

I see, a bit like EasyCAT kind but for the voltage reader.
 

I am more into putting the torch voltage reader components onto the EaserCAT board.
Now when I have looked at it I am not so worried about the voltage levels and that.
One just need to take some precautions.
And if I understand right, most new plasma cutters gives out scaled down voltage
so it is more to handle the floating voltage, and this circuitry does that.