Advanced Search

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. 

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

PCW wrote:

File Attachment:

File Name: 7i96sd_esdid.zip
File Size:250 KB

Hi Peter, 
I am the one who just ordered the 7i96s and 7i84u and talked about needing to read four index pulses. 
Is this the FW, I would need to make it work?

All best and thanks for the guiding on email, too,
David 
 

that is, I would try it with a configuration for 4 axes, it can probably be done as a lathe config with ``spindle synchronized motion'', but I have no experience on that topic.

hello, the question is interesting but the fact should be taken into account, the feedrate for the linear axis is understood by the configuration as mm/min, but for the rotary axis it is understood as deg/min. so depending on the transmission on the A axis the example shows that the same feed is for both x and A, mechanically the two speeds should be matched. of course it also depends on the thickness of the wire you are winding, so I would personally try to solve the problem by exporting gcode from a program that supports constant rotary operation, I know it can be done in ``deskproto'' and maybe I would try to define a stepover via the definition processing tools (for example, the endmill 1mm tool replaces a 1mm wire in practice, stepover 1mm as well), I would subsequently edit such a gcode to support cycle repetition. it is essential that the CAM program outputs adequate A and X feedrates to synchronize the movement.

hello, I managed to insert the firmware, I managed to ping my nvemV2 10.10.10.10, i also managed to do halcompile, i also transferred some of the basic configurations... unfortunately, starting linuxcnc via the command line, I get a blank, i.e. I can't start either one of the configurations. do you have any ideas? Thank you      

Thanks for your reply, tommylight.

Unfortunately, HOME_FINAL_VELOCITY is set appropriately.
The Homing parameter uses the value set in LinxCNC2.8.3.

Based on my experience adjusting the servo using AT-PID at that time, I think the PID module in 2.9.3 may have been replaced with AT-PID. I remember that AT-PID did not work properly even when connected to the Index-enable pin with JOINT and Encoder Index-enable.

Has anyone experienced this problem?

Thank you in advance.