Advanced Search

You can try this rt kernel for the rk3399:
drive.google.com/drive/folders/12VfNmKC3...feCnnzYX?usp=sharing

For the spi rt patch I'll see if I'm able to do something. For sure it won't be as complete as the "original" patch but maybe it'll be good enough.
Have you already been able to use the spidev driver at all?

A couple of things:

You should use reset mode for all axis/spindle
this should double you maximum step rate

Can you post your current hal/ini files?

maybe it seems need looking for a more complex path , because in the second cycle the diameter of the cylinder already changes for the thickness of the material being rolled (inversely proportional to the thread cutting on the lathe), another possible problem is the material itself, because in theory, A axis or S must make one revolution to move the linear axis for one stepover (material thickness), but as in practice material deviation occurs, I am very skeptical that they can guess the speeds. I used deskproto'' to export gcode for 4 axes with the path ``continues rotary'', where it has the basis of the speed of the linear axis and the stepover, as well as the diameter of the workpiece, so it calculates the speed of the A axis. but this is a hard material and then it is an accurate measure..www.youtube.com/shorts/OOtRMBdZchk

PCW wrote:

Yes, this firmware should work (though would need to be modified to add the fourth axis index input)

Great, thanks.
4th is in the future, no need for it for a while:)

 

Yes i think that is the way to go. but I am curious to find out if it is also possible to do it while configured as an A Axis?

secondly, i have a parallel thread on going the discussion of a spindle, where i am not able to attain the max rotational speed when my motor is configured as a spindle compared to as an A axis (where i get more rpm).

forum.linuxcnc.org/16-stepconf-wizard/54...-par-port-stepconfig

help is much appreciated

Sounds like you should maybe run it as a spindle instead of axis A.

yes, to match the feedrates when two axis are called simultaneously within a single line of code, the gcode calculates a compound feedrate, with the X axis as master, and the A axis as slave. so basically the X axis dictates how fast the A axis would rotate. i do not want this.

i want the A axis to be rotating continously at a given feedrate.
and X to perform back and forth motion (based on the material width that i have, so that i can acheive a side-by-side layup of the material) the material parameters are mentioned on the above reply of mine.

diameter of the mandrel = 100mm
length of the tube to be wound = 300mm
material speed (to be wound per second) = 100mm/s
material width = 6.35mm
material thickness = 0.14mm (lets ignore it at the moment for a simple program)
requirement = side-by-side layup of material without any gaps and overlaps

and how about the other terms,
SCALE = 6400
DIRSETUP = 10000
DIRHOLD = 10000
STEPLEN = 5000
STEPSPACE = 5000

because i noticed that if i keep scale as 800, then the spindle rotates very slowly.
what values should the rest of the terms, dirsetup, dirhold, steplen and stepspace should have to maximise the rpm.

i certainly can see that when the motor is set as A axis(with max values), it turns faster than with my current settings as spindle.

Exactly:
When I set up mesact I missed a value on the Settings page for the global Linear Velocity which is in addition to the individual axes values
Set that to 15 and I have motion on G0

Many thanks

For $214 a pop I can purchase 1000w 220v servo motors with drivers. Really does not seem to unreasonable I'm not really sure tho if this would be way overkill but I figure it's better to go bigger and work the motor less. I included a link below. Is there any disadvantage to running a set up like this? I think I will stick with the original motors to get the machine running but I'd like to understand more about servo vs stepper.

www.amazon.com/RATTMMOTOR-Encoder-Contro...54&sr=8-4&th=1&psc=1

Not sure if this applies to your setup but classicladder does not seem to work with [HAL] TWOPASS = on

Little update I completed the sheet metal storage rack for my plate processing operation. Posted a few pics below. Going to get started on setting up the plasma table. I need to design a water table so I know what height to build the gantry to. Do you think it's worth it to obtain a few more of those steppers? I can hunt down more of these redbox machines to rob them from. Do you think they would have the power required to drive the gantry? I estimate it's 3-500 lbs I like the idea of high precision. I don't think I would save much money after wasting the time to aquire the redboxs tear them down etc but if there high quality components and really special it may be worth it. Got any expereince with water tables? Know of any good designs to work off of? Seems like a good amount of engineering is required to make sure it's strong enough to not collapse alot of weight is put on em aswell as I want to be able to raise and lower water height automatically, maybe even control it electronicly with electro pnumatic valves. 

royka wrote:

The SPI driver has nothing to do with Armbian, it's in the kernel, it seems to be a known issue with the default (example) driver. Unless their is a proper SPI driver for the rk3399 it won't be different on that sbc. AFAIK there's only made a realtime driver for the RPI.
Unfortunately I don't have a spi board to test with, perhaps it helps to pin the irq of spi to an isolated core?

I've seen that there has been a rt patch for one board for a quite old kernel, I can try to find that one and if I'm able to apply that on the newer kernel.
 

Is there really a real-time kernel version for the rk3399, like the one for Raspberry Pi? Because I haven't been able to find anything about it.Also, if you manage to find something useful with the older kernel, I’d really appreciate it if you could let me know. Thanks

Just tested on master and it seems it fails to show the correct 'current_line = 5' during the first run right after starting the config. After that it works for me.
Not sure why it fails the first time though other than that ''current_line" does not seem to update before an actual move of axis has taken place.

[edit]
The other thing that seems like a bug is that 'mcodes' always contains 'M0'.