ubuntu 14.04.1 linuxcnc help

Question about my previous post

I guess I should have been more direct about my concern of schematic. Not looking for someone to check my work just wondering if it is ok to use same Step and direction output from BOB to drive two separate motor drivers such as the way I have X axis setup in schematic. And is this the correct way to set up gantry-hs and adding the extra axis of A as motor 04. In sim while in joint mode I see four axis in display which are not labeled, I was thinking I should see five X, Y1, Y2, Z, A

Tim

tjmarch wrote: just wondering if it is ok to use same Step and direction output from BOB to drive two separate motor drivers such as the way I have X axis setup in schematic. And is this the correct way to set up gantry-hs

If it works for you, then it is correct.

There are many ways to make this work. Starting at the motor:
Both sides can be driven by one motor, via a shaft.
Both motors can be driven by the same driver, in series or parallel. (serial is probably better, but you need double the voltage)
Both Drivers can be driven by the same step-dir signal

---

into software----
Both step-dir signals can be drive by the same stepgen
Both stepgens can be driven by the same joint position
Both joint positions can be driven by the same axis position.

Which do you prefer? We can tell you how.

Andy
Thanks for the quick reply

Starting at the motors for Y axis:
Not one of the choices you gave me but I would like if possible:
Each joint Y1 and Y2 to have separate motor drivers with separate step-dir signals to each motor driver
If that is not possible I would go with
Two Drivers that can be driven by the same step-dir signal

Y1 and Y2 will both have separate belt and pinion drives with nema 23 motors like this

---

into software----
1. I would like Y1 and Y2 to work together in world jog mode and to run gcode
2. And independently in joint jog mode for squaring up gantry

Out of the choices that you gave me not sure what would be best to achieve above needs but thinking
Both step-dir signals can be drive by the same stepgen

Tim

After careful consideration, and multiple tests between 32 and 64 bit rt kernels, imho, the rt kernel on a 32 bit ubuntu 14.04 os should not be considered as a viable machine controlling platform.
Latency is much more irradic and even reassigning process priorities dos not fix these spikes.
64 bit system shows a bit of instability in its audio processing capabilities with no process changes but changing the nice value from "very high" in both hd audio and pulse audio seems to fix this.
tim
view the screen shot i listed as personal reference and not that i did not suffer the initial spike like you saw on your system. this is in part due to process tweaks i made and opening the plot in a clean environment. i then opened all the other operations one by one till the cpu ramped up.
this may or may not be defeating the purpose of the test but i was able to run glxgears, massive file copies and music playing full blast with those results after an hour. it may not be as conclusive as 11 hours but for the first time i have a consistent result .
Also the performance of the 32 bit os is noticeably more sluggish than the 64 bit. i will attach the amended 32 bit .sh file for anyone else to test the diff. we would love to here others results to help prove/disprove these results, or if i fat fingered something let me know.
thanks
jason

these are a comparison betwen 64 and 32
same kernels, same grub same everything... the 32 bit is on top.
This leads me to wonder about posible improvements for the 32 rtai kernel in 64 bit os..
tests to come soon...
then on to linux mint. both kernels on both os'.

Things left to do..
Tests of rtai kernels on both kernels ubuntu,
Tests of linux mint, half the testing has already been performed by tim.
figuring out how to permanently change niceness value for specific processes,
turning on fan full speed through grub,Future possibilities may include modifying of configuration for 3.18.24 rt kernel layered with ubuntu patches for a fully functional ubuntu os.. (Yes its true app armor does not work with the kernel we are testing. )
there are instructions on linuxcnc wiki to make the grub configurations only load with a specific kernel. this would be very useful if the 3.18.24 kernel is a bust...
if the 3.18.24 kernel is successful, i can be made into an iso, with the included changes i previously mentioned?
Any thoughts? Is this a bad idea?