Advanced Search

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'.

 

Open a terminal (Ctrl+Alt+t) and enter this command
then choose your config and check for errors in the terminal output.

In /etc/default/grub:

GRUB_DISABLE_SUBMENU=true

You will need to modify the file with superuser permissions, but if you're new to Linux, using vim or nano might be too tedious. You can use something like:
or:and then launch the graphical editor as a superuser like so:or:I'm not on Debian right now, so if gksudo doesn't work, try gksu, and if that doesn't work, then resort to using `sudo` instead. Common practice is to never use `sudo` though for graphical applications.  After modifying /etc/default/grub (there should be a comment already in the file about GRUB_DISABLE_SUBMENU) run:Now count the number of menuentries starting from 0, then make that your `set default=` setting. Afterward, re-run:command again.

Index (Z pulse) Homing on Delta Servos 

I hope it's OK I add a bit more info to this thread specifically in regards to Delta servos. I bought some used ones quite cheaply. To me, it's a better deal than the no name ones as the Deltas have much better documentation and a proper tuning/setup software. (Actually, I am almost sure at least some of Automation Direct's servo series are rebranded Deltas, too.)

Earlier in the thread PCW mentioned a potential speed issue where the Mesa input may not be fast enough to read the index signal unless the index is somehow slowed down. But perhaps the following tidbit I found will help with this (it's from a different controller manufacturer describing  how to wire up index homing  ):

For proper operation it is necessary to rearrange DELTA drives default settings. Number of pulses of drives’ output encoder – should be shifted to a lower value to ensure adequate INDEX signal pulse length. P1-46 parameter set by default on 2500 pulses – set on 500 pulses per rev or less. This change has no influence on servo drives working precision because their internal procedures work on encoder full accuracy anyway.

PCW also suggested on email that I slow down the homing speed (home to regular limit/home switch can be faster, but then slow down the home to index/Z pulse after that). So, maybe a combination of lowering the pulse value for the encoder and slowing down the home speed a bit is the ticket.

Again, if you have B3s, A2s or perhaps A3s(?) you can try making the servo drives handle the homing routine.