Re: [Emc-users] G0 Moves and Path Blending?

[Marius Alksnys]

11/04/2016 12:57 PM, sam sokolik rašė:
> I know during testing at some point the G0 -> Feed moves and feed moves
> -> G0 were exact stop.  I think it was changed to make it act like it
> did with the previous TP.   My thoughts at the time was to make it a hal
> pin or maybe a INI setting.
>
> sam

Please, don't do this. This setting has to be dynamically selectable and 
controlled from G-code.

I had at least one case where sluggishness of G0 full-stops drove us 
crazy. Instead of going around the workpiece it "danced" stopping at 
each of 6 or 8 corners. And time was important there. We could not find 
another solution like to use G1 and insane feed-rates. This was 5 axis 
machine and those feed-rates where interpreted in degrees and/or 
millimeters..


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Carousel component questions

[Marius Alksnys]

Hello, Jan,

this is my carousel HAL component version. I made it more reliable, was 
tested a lot and is working on a real machine. Sense-pocket is low when 
carousel is fixed and high between positions. Sense-index occurs between 
positions AFAIR.
Might require changes because of hard-coded sensor states it expects. I 
used it with M6 re-mapping, thus used analog-out for socket number.
Here is the code:

component mycarousel "Orient a tool drum custom component";
// partly derived from andy-pugh carousel HAL component

pin in  float pocket-number-f "The pocket to move to when the .enable 
pin goes high. Float to be compatible with motion.analog-out";
pin in  bitenable "Set this pin high to start movement. Setting it 
low will stop movement";
pin in  bitunhome "Unhomes the component and forces to find index 
again";
pin out bitactive "indicates that the component is active";
pin out bitready "This pin goes high when the drum is in-position";
pin in  bitsense-index "Drum index position feedback pin";
pin in  bitsense-pocket = true "Drum pocket position feedback pin";
pin out bitmotor-fwd "Indicates the motor should run forwards 
(bigger numbers)";
pin out bitmotor-rev "Indicates the motor should run reverse";
pin out bitis-ok = true "No fault output";
pin out signed pos = 0 "This pin indicates the current position feedback";
pin out bithomed = false "Shows that homing is complete.";

param r  signed state = 0 "Current component state";
param rw signed home-pocket = 19 "Pocket number at index.";
param rw signed pockets = 21 "Pocket count in drum";
param rw signed timeout-one = 60 "Maximum time to wait for next pocket 
in thread periods";
param rw signed timeout-all = 1600 "Maximum time to rotate to any pocket 
in thread periods";

license "GPL";
author "andy pugh, Marius Alksnys";

variable hal_bit_t old_sense = false;
variable hal_bit_t old_index = false;
variable hal_s32_t timeone = 3;
variable hal_s32_t timeall = 3;
variable hal_s32_t pocket_number = 0;

function _ fp;

option singleton yes;

;;

#include 

#define ST_WAITING 0
#define ST_HOMING_INDEX 10
#define ST_FINISH_HOMING 20
#define ST_CHOOSE_DIR 30
#define ST_MOVING 40
#define ST_STOP_AT_POCKET 50
#define ST_DONE 60
#define ST_HALT 96
#define ST_HALTED 99

#define MSG_SOURCE "Tool carousel: "

FUNCTION(_) {
 if (unhome) homed = false;
 if (sense_pocket && !old_sense) { // Pocket sensor signal just rised!
 timeone = timeout_one;
 if (homed) {
 if (motor_fwd) {
 pos += 1;
 if (pos > pockets) pos -= pockets;
 }
 if (motor_rev) {
 pos -= 1;
 if (pos < 1) pos += pockets;
 }
 if (!motor_fwd && !motor_rev) {
 homed = false;
 state = ST_WAITING;
 rtapi_print_msg(RTAPI_MSG_ERR, MSG_SOURCE "got socket 
sensor signal, while no command to turn. Will re-home.");
 }
 }
 }
 old_sense = sense_pocket;

 if (sense_index && !old_index) { // Index sensor signal just rised!
 if (homed) {
 if ((motor_fwd && (pos != home_pocket)) || (motor_rev && 
(pos != home_pocket + 1))) {
 state = ST_HALT;
 rtapi_print_msg(RTAPI_MSG_ERR, MSG_SOURCE "home sensor 
signal at wrong time (very big risk to brake equipment), component will 
halt!!!");
 }
 }
 }
 old_index = sense_index;

 if (is_ok) {
 if (sense_pocket && sense_index) {
 state = ST_HALT;
 rtapi_print_msg(RTAPI_MSG_ERR, MSG_SOURCE "both sensors 
active (very big risk to brake equipment), component will halt!!!");
 }
 if (active) { // Checking for timeouts
 if (timeone-- < 0) {
 motor_fwd = false;
 motor_rev = false;
 active = false;
 is_ok = false;
 state = ST_DONE;
 rtapi_print_msg(RTAPI_MSG_ERR, MSG_SOURCE "time-out 
waiting for one position!");
 }
 if (timeall-- < 0) {
 is_ok = false;
 state = ST_STOP_AT_POCKET;
 rtapi_print_msg(RTAPI_MSG_ERR, MSG_SOURCE "requested 
position time-out!");
 }
 }
 }

 switch (state) {
 case ST_WAITING: // waiting at start
 if (! enable) return;
 timeall = timeout_all;
 if (! sense_pocket) {
 homed = false;
 rtapi_print_msg(RTAPI_MSG_ERR, MSG_SOURCE "carousel was not 
fixed before rotating. Will re-home.");
 }
 active = true;
 pocket_number = round(pocket_number_f);
 if (!homed) {
 motor_fwd = false;
 motor_rev = true;
 timeone = timeout_one;
 state = ST_HOMING_INDEX;
 break;
 }
 state = ST_CHOOSE_DIR;
 ready = false;
 case 

Re: [Emc-users] X on pi-3?

[Marius Alksnys]

I don't know if this would help, but I found out LC_ALL=C to work when 
testing LinuxCNC with different translations, locales..
Sample command: LC_ALL=C LANG=ru LANGUAGE=ru_RU /usr/bin/linuxcnc 
'/home/cnc/linuxcnc/configs/tests/test.ini'

11/06/2016 05:34 AM, Gene Heskett rašė:
> But $LC is still
> missing from an env report  And, its not set on this machine either.
> Whats it supposed to be? Or can it be ignored?


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 22:30:04 Gregg Eshelman wrote:

> Can Damn Small Linux run on the Pi? There are several quite small
> Linux distros.

No clue Gregg, and cannot recall reading of it in the Pi context. google 
has quite a pile of links, ought to be edyoukational reading.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Danny Miller]

How does inverse-time work?

Say you specify 1 sec to do 1" for a single vector not connected to 
other cuts, so it starts/stop fully at the ends.

Is that the same as F=60ipm, which will take longer due to accel/decel?


Or does it guarantee that the whole cut will take 1 sec, which will go 
faster than 60 ipm in the middle?

Danny


On 11/6/2016 2:23 PM, andy pugh wrote:
> On 6 November 2016 at 20:09, Danny Miller  wrote:
>> Huh, ok, yeah inverse-time does make sense.
> A little less sense than not-inverse time. In my opinion.
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Gregg Eshelman]

Can Damn Small Linux run on the Pi? There are several quite small Linux distros.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Erik Christiansen]

On 06.11.16 20:21, Gene Heskett wrote:
> So, one question, will the udoo service the 7i90HD over an SPI 
> connection?  If it will, I might blow another $150 trying it.

Looking at the udoo "datasheet.pdf" (more glossy shortform chart than
real datasheet), under "Other Interfaces", there's LPC, 2 I²C, 20 GPIO,
Touch Screen Management Signals on expansion connector." I'm confident
that I²C is the same thing as TWI, but SPI is a simpler protocol with
more wires:

http://www.byteparadigm.com/applications/introduction-to-i2c-and-spi-protocols/

That's why I'd lean toward using some of the 20 GPIOs as a parport,
though that would necessitate coding a device driver. It'd be faster
than SPI. Bit-banged, it'd be better suited to output than input, but
that's what's needed, AIUI.

It'd be too big an exercise to move the TP & HAL to the spare on-board ARM
chip, on the other side of a USB link, especially as Machinekit is
hewing that type of path through the jungle already, but it would put
the whole split system on one board. (Very compact) As you've indicated,
the modest USB latency would be inconsequential in that case.

Mind you, it's not even necessary to move the TP to the RT CPU if:
a) It works ahead and sends moves to a queue on the other side of the
   USB link.
b) Each move includes any delay information required to reconstitute
   timing after the queue. (I.e. TP separate from Trajectory scheduling)

RT is still RT, even if everything is time-shifted.

> > About the cable.  Just don't worry about oil.  oil does not conduct.
> 
> I know that, but I have had hand lotion destroy microphone cables.  
> Litterally dissolveing the usual grey vinyl jacket in 6 months of news 
> talent putting on the news at WDTV.

Dunno if they sell Aeroguard in the land of Trumpetman, but mere vapours
of that mossie repellent ate the soft jacket off my car USB charger
cable in less than one month. (Not hard to understand why it keeps the
mossies off.)

Good luck with offloading the X workload. That seems to be the recipe
for getting an RPi up to the surface of the quagmire so you can see it
moving. (Though since it even boots slowly, that's not a perfect fix.)

Erik

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 16:28:38 Chris Albertson wrote:

> Don't under estimate the power of simply exporting X11.   As an
> example a very small amount of data goes over the network that might
> say "move that window 75 pixels to the left" and then the x-server has
> to change the value of 350,000 pixels and maybe remember the values of
> the ones covered restore the values of the ones uncovered.  It is MUCH
> better then sending raster graphics over the net.   It also moves
> calculations of about clipping and renders vector graphics to rater
> all onto the server  If using openGL al lot of complex matrix math can
> be pushed off to the computer with the physical display.

Well, after today I am ready to rip it back out and go back to an x86 
based system.

1. much more so on its own console, but occasionally from here, the 
keyboard either goes dead for some random amount of time, which I think 
might be related to mouse pointer position AND somewhere its set for 
focus follows mouse. Its better from this keyboard than any keyboard 
attached to it because I don't think the mouse pointer position counts.

2. after setting a root pw so synaptic might work, things are so screwed 
I'm tired of beating my head and back up over it.

3. After trying a 2nd brand new keyboard and mouse and getting the same 
results, much worse with x installed, I am convinced that the armhf 
version of xkb is one busted piece of S---. I just spent much of an hour 
trying to add 9 lines to the halfile to enable 3 outputs to control the 
vfd, and failed.

At the moment I cannot login from here because I was dumb enough to tell 
raspi-config to wait for a login before starting the network.  And 
because of the poor keyboard response, its impossible to type my user pw 
because it will either skip characters, or go wild because it missed a 
key-up event, and despite setting the repeat for slow and slower, it 
will go off and put 50 characters of the last key pressed into whatever 
I an editing before I can react and tap a different key. Continueing at 
50 chars a second until I hit another key.  Then if I try to backspace 
over the extra characters, like as not the backspace key will hang and 
erase not only what I was typing, but 4 or 5 lines of a hal file that 
was already there.

Anyway, its essentially bricked now until the sd card is re-imaged.  And 
I had just added it to amanda's nightly backup duties early this 
morning, so the backup is no good either since the first one won't be, 
no network.

I might be able to work around it IF the term was terminal-4.8, but its 
not. I've tried every terminal in the menu's, and none of them are big 
enough to be usefull as a default, and none have a resize drag border or 
corner, I tried all 3.  Postcard sized doesn't cut it.
So, one question, will the udoo service the 7i90HD over an SPI 
connection?  If it will, I might blow another $150 trying it.  The extra 
60 is like doing an engine swap, where 50 years ago it was a given that 
you bring the engine, and the adapter kit, the torch with full bottles,  
and $500 (in 1955 money) for the other stuff it takes to make it all 
work. BTDT, several times.
>
> About the cable.  Just don't worry about oil.  oil does not conduct.

I know that, but I have had hand lotion destroy microphone cables.  
Litterally dissolveing the usual grey vinyl jacket in 6 months of news 
talent putting on the news at WDTV.

> Remember many larger size transformers live in an oil bath.  Flooding
> them with oil keeps the water out.

I know that too haveing soaked my arms in the askarol or whatever pcb was 
in them, repairing burned up connections 18" under the oil's surface, 
once in a 250 kw rated box, probably north of 10,000 lbs. 3 times in my 
broadcasting career.  You shower daily, and you still stink for about a 
month afterwards. I started my youngest while I still had some of the 
smell on me. Getting him, born deaf and on predigested formula for the 
1st 5 years, up to his teen years took quite an effort. Now at about 40, 
he eats what he wants, and much to the surprise of the docs at the Mayo 
Clinic, he now hears at least as well as I do. I will always connect the 
dots on him getting started, and me being contaminated with that crap.

> It is only the wire insolation 
> might care or not about oil.

This wire is stranded, so no varnish. Lose the vinyl and its toast.

So I'll not putz with this, but work on the hardware until the orangepi 
gets here. I'll redo the u-sd without x, and see if I can ship the x 
stuff to the Orange-Pi-3 for rendering.

At that point I'll need a fresh recipe for building the u-sd card(s), I 
still have 2 virgin 32GB cards in the blisterpack.
[...]

Thanks Chris.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: [Emc-users] max_velocity during execution - multiple axis

[andy pugh]

On 6 November 2016 at 20:09, Danny Miller  wrote:

> Huh, ok, yeah inverse-time does make sense.

Someone has written a utility that tries to convert existing G-code to
inverse-time G-code:
https://www.youtube.com/watch?v=d0ffiCekhpE

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

I think what Robert propose is great - to push current TP little bit
further so planning could take care of ABC axes could be used along XYZ in
inverse time (g93) mode and with g01 moves.

In my case rotational axis A is actually rotating workpiece around Y axis
and radius of A is always easy obtainable as sqrt(x^2 + z^2). For passing
radius of rotation to tp - I would prefer to have some dynamic method wich
means that change of radius will not require restarting lcnc.

I am willing to test such tp as it become available. I have machinekit
simulation in place so with two gcodes results could be seen quite fast - I
could record video or take output on some other intermidiate results.
Test case goal would be, that also with small rotational acceleration and
big rotational velocity limit, tp could plan it in a way that this large
velocities are reached in such cobined small segments of gcode.

I think we should focus to workpiece velocities (as I know all tool
limitations like max speeds or recomended speeds are refering to tool to
workpiece relationship) - but I think:
*motion.current-vel* (OUT FLOAT Current cartesian velocity) refers only to
vector sum of v_x,v_y and v_z. It doesnt take into account rotational
angular speed of A.



On Sun, Nov 6, 2016 at 10:46 PM, Chris Albertson 
wrote:

> If you can compute inverse kinematics for the general case then the
> software in effect "moves" the TP at the desired rate while using inverse
> kinematics to compute the required motor rates.   Planning has to consider
> the motor rates and if the rate is within limits.   Perhaps (I've not read
> the code) LinuxCNC works in a machine centric cordinate system
>
> I think if the goal is to limit TP rate/acceleration relative to the metal
> being cut then you need work in the stock-metal's coordinate system
> The hard part might be transforming the DH from machine centric to stock
> centric.
>
> I think this is the same problem a two handed human might have if
> "machining" a block of wood held in one hand with a die grinder tool in the
> other hand.  Best to do the computation as if the woodblock were stationary
> and the human was spinning around somethings with feet in the air.
>
> I admit IK is a hard problem.   I have a six leg, 18 DOF machine but I
> cheated and hard coded the IK.
>
> On Sun, Nov 6, 2016 at 1:14 PM, andy pugh  wrote:
>
> > On 6 November 2016 at 20:54, Chris Albertson 
> > wrote:
> > > There is already an industry standard for describing the general case
> of
> > > rotary and translational links bolted together serially and even better
> > > already software for working out the kinematics and joint and movement
> > > rates and accelerations
> >
> > LinuxCNC supports general serial kinematics defined by
> > Denavit-Hartenberg parameters using the genserkins module.
> >
> > This is a somewhat different problem.
> >
> > If using genserkins (or any other TCP kinematics) then the existing
> > XYZ blending is all that is needed, as _only_ XYZ moves result in a
> > tool tip motion. ABC moves simply alter the tool orientation abit that
> > point.
> >
> > The problem to be addressed here is somewhat different.
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1916
> >
> > 
> > --
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list

Re: [Emc-users] max_velocity during execution - multiple axis

[Chris Albertson]

If you can compute inverse kinematics for the general case then the
software in effect "moves" the TP at the desired rate while using inverse
kinematics to compute the required motor rates.   Planning has to consider
the motor rates and if the rate is within limits.   Perhaps (I've not read
the code) LinuxCNC works in a machine centric cordinate system

I think if the goal is to limit TP rate/acceleration relative to the metal
being cut then you need work in the stock-metal's coordinate system
The hard part might be transforming the DH from machine centric to stock
centric.

I think this is the same problem a two handed human might have if
"machining" a block of wood held in one hand with a die grinder tool in the
other hand.  Best to do the computation as if the woodblock were stationary
and the human was spinning around somethings with feet in the air.

I admit IK is a hard problem.   I have a six leg, 18 DOF machine but I
cheated and hard coded the IK.

On Sun, Nov 6, 2016 at 1:14 PM, andy pugh  wrote:

> On 6 November 2016 at 20:54, Chris Albertson 
> wrote:
> > There is already an industry standard for describing the general case of
> > rotary and translational links bolted together serially and even better
> > already software for working out the kinematics and joint and movement
> > rates and accelerations
>
> LinuxCNC supports general serial kinematics defined by
> Denavit-Hartenberg parameters using the genserkins module.
>
> This is a somewhat different problem.
>
> If using genserkins (or any other TCP kinematics) then the existing
> XYZ blending is all that is needed, as _only_ XYZ moves result in a
> tool tip motion. ABC moves simply alter the tool orientation abit that
> point.
>
> The problem to be addressed here is somewhat different.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

On Sun, Nov 6, 2016 at 4:18 PM Chris Albertson 
wrote:

Just to clear up,  DH allows you to specify any set of translation and
rotation devices, one mounted on the other.   The normal XYZ mill is very
simple case, but as soon as you bolt on a rotary table, especially if the
axis of ration is not parallel to the XYZ axis is gets complex.

The best feature of DH is that is already list software that can compute
forward and inverse kinematics from a file of DH parameters, you don't need
to write that very dificult part.

In fact you can have high acceleration rates of the tool path even while
the motors are running at constant speed.  Computing a motor speed so as to
keep acceleration and velocity under a specified limit is non-trivial.  But
the problem is solved.  Google will return thousands of hits


Naturally, there are many such solutions. My point was that integrating
them into LinuxCNC will require a major overhaul. If we want something
workable quickly, a hack solution to the existing trajectory planner may be
enough for simple cases like a fixed rotary axis.

If our long-term goal is optimal motion planning for a general robot, then
it would be smart to use an existing motion planning library, rather than
to roll our own.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Chris Albertson]

Don't under estimate the power of simply exporting X11.   As an example a
very small amount of data goes over the network that might say "move that
window 75 pixels to the left" and then the x-server has to change the value
of 350,000 pixels and maybe remember the values of the ones covered restore
the values of the ones uncovered.  It is MUCH better then sending raster
graphics over the net.   It also moves calculations of about clipping and
renders vector graphics to rater all onto the server  If using openGL al
lot of complex matrix math can be pushed off to the computer with the
physical display.

About the cable.  Just don't worry about oil.  oil does not conduct.
Remember many larger size transformers live in an oil bath.  Flooding them
with oil keeps the water out.   It is only the wire insolation might care
or not about oil.

On Sun, Nov 6, 2016 at 12:34 PM, Gene Heskett  wrote:

> On Sunday 06 November 2016 12:35:40 Chris Albertson wrote:
>
> > On Sun, Nov 6, 2016 at 1:14 AM, Gene Heskett 
> wrote:
> > >  My newest concern is the poor
> > > bogomips I see in dmesg. Only 153 for all 4 cores. This machine has
> > > 17682.
> >
> > In case you did not catch it, "bogomips" is short for "bogus MIPS".
> > In other words a worthless measurement pf speed.
> > The processor used in the Pi 3 actually runs  at just a little over 1
> > MIP per GHz (more or less.)
> >
> > If you are seeing poor performance with remote X11, I'd suspect poor
> > network in performance.  The best networking performance will be to
> > use a USB 1000 BaseT dongle You will not get full gigabit level
> > performance but it will outperform the built-in 100 BaseT interface.
> >  Then make sure you have a gigabit switch going to the PC.   The
> > advantage here is that you are NOT running an x-server on the Pi 3.
> > Any work you can off load from there Pi 3 is good.   Check memory
> > usage using "top"
> >
> It seems to me, the best, cheap link would be to usb-2 to usb-2, which
> gives 480 megabits each way, at the expense of some latency. However,
> since the hal is running on the machine connected to the machinery, the
> latency would be visual, and I don't believe that an extra 20ms due to
> the physical links inherent latency would be a detectable problem.
>
> The problem as I see it, is in telling the usb system its ok to have a
> std board socket at both ends of the link, and locating a short, as in
> 6-8 inches, usb to usb cable.
>
> > The Machine kit people (if I understand it correctly) are breaking up
> > LinuxCNC to run as a set of independent processes that communicate
> > with messages.If Im right then it looks like the goal might be to
> > have the ability to run the GUI on a different computer then HAL.
> > This is the best design, not exporting the display, but the entire GUI
> > program.
>
> That make more sense to me than just exporting x commands to a different
> server.
>
> Now, I've had some breakfast and went to the garage to check it for first
> impressions. But am back quickly, in severe back pain because I forgot
> to take the morning pills, so the gabapenten hasn't had time to work.
>
> 1. Mouse is swimming in very cold corn syrup, and speeding it up in the
> mouse prefs makes no difference.  Not a show stopper, but distracting.
>
> 2. Linuxcnc is just as slow at opening its screen, and eventually drawing
> the full lcnc screen there as it is here. 15+ seconds to a fully drawn
> display.
>
> 3. Running the LinuxCNC logo, it ran normally.  Mouse no slower when lcnc
> is running, so this is AFAIAC a mouse problem in x. Running the same
> mouse/kbd on the Dell I disconnected, the mouse was best described as
> spastic, is now smooth and noticeably slow moving.  Microsoft kbd and
> mouse, and kbd known to not send timely keyup's. I'll check for weak
> batteries but the real fix for that keyboard is a logitech K-360 as the
> range to the dongle is way too short too. 3 feet max, <1 foot for no
> missed keys.
>
> I should get some bi-color leds, steering diodes and some suitable
> current limiting R's and put them where the motors hook up so I can see
> the motors "running" while its sitting on the table yet.  That, and get
> the encoder finished.
>
> I'm still debating on how to best get the encoders cable out of the
> spindle casting tub. Too much oil if I run it under the gears to one of
> 2 holes in the rear of the tub. And potentially too close to spinning
> gears. One thought is to drill a hole near the lower front, tipping the
> drill as I go so a hunk of 3/8" SS tubing can be cut so as to drop thru
> the casting and down thru the standoff spacer bar where the QCGB used to
> be. That SS tubing is tough stuff, and cannot be bent by my tubing
> bender intended for similarly sized copper. That casting is also hard
> drilling, needing drill bits fresh from a drill doctor.
>
> 4. I get the impression the thing might work, if the mouse moved like my
> hand. That slow, 

Re: [Emc-users] max_velocity during execution - multiple axis

[andy pugh]

On 6 November 2016 at 20:54, Chris Albertson  wrote:
> There is already an industry standard for describing the general case of
> rotary and translational links bolted together serially and even better
> already software for working out the kinematics and joint and movement
> rates and accelerations

LinuxCNC supports general serial kinematics defined by
Denavit-Hartenberg parameters using the genserkins module.

This is a somewhat different problem.

If using genserkins (or any other TCP kinematics) then the existing
XYZ blending is all that is needed, as _only_ XYZ moves result in a
tool tip motion. ABC moves simply alter the tool orientation abit that
point.

The problem to be addressed here is somewhat different.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Chris Albertson]

Just to clear up,  DH allows you to specify any set of translation and
rotation devices, one mounted on the other.   The normal XYZ mill is very
simple case, but as soon as you bolt on a rotary table, especially if the
axis of ration is not parallel to the XYZ axis is gets complex.

The best feature of DH is that is already list software that can compute
forward and inverse kinematics from a file of DH parameters, you don't need
to write that very dificult part.

In fact you can have high acceleration rates of the tool path even while
the motors are running at constant speed.  Computing a motor speed so as to
keep acceleration and velocity under a specified limit is non-trivial.  But
the problem is solved.  Google will return thousands of hits



On Sun, Nov 6, 2016 at 12:54 PM, Chris Albertson 
wrote:

>
>
> On Sun, Nov 6, 2016 at 9:48 AM, Robert Ellenberg  wrote:
>
>>
>> The hard part is making the effective radius change with tool tip
>> position.
>> That's my long-term goal with this fix, but it may still be a big
>> improvement to assume a constant effective radius.
>>
>
> I assume what you need is to know the location of the axis in XYZ space.
> This would have to be input for each set up and would depend on how you
> bolted the rotary table to the mill table.  In the general case the rotary
> table might be bolted to some other rotary table and so on.  This actually
> happens in the case of an industrial robots
>
> There is already an industry standard for describing the general case of
> rotary and translational links bolted together serially and even better
> already software for working out the kinematics and joint and movement
> rates and accelerations
>
> A good introduction is here: https://en.wikipedia.org/wiki/
> Denavit–Hartenberg_parameters
>
> If you google Denavit-Hartenburg you will find software to read this
> description and to visualize it to a computer screen
>
> The job then of supporting the full general case because one of software
> integration, not inventing new methods
>
> Think of apian spray machine where the paint nozzle must always be kept at
> a fixed distance and angle from the car fender being sprayed and must
> always move at a fixed rate measured tangent to the surface.  These spray
> machine are made mostly of rotary joints were the servo motors are
> controlled to a given angular rate.   A walking robot has the same
> problem.  Its foot must stay on the ground while the robot translates in
> the direction of motion.  The problem is common and open source solution
> exist
>
>
>
>
>>
> --
>
> Chris Albertson
> Redondo Beach, California
>



-- 

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Chris Albertson]

On Sun, Nov 6, 2016 at 9:48 AM, Robert Ellenberg  wrote:

>
> The hard part is making the effective radius change with tool tip position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>

I assume what you need is to know the location of the axis in XYZ space.
This would have to be input for each set up and would depend on how you
bolted the rotary table to the mill table.  In the general case the rotary
table might be bolted to some other rotary table and so on.  This actually
happens in the case of an industrial robots

There is already an industry standard for describing the general case of
rotary and translational links bolted together serially and even better
already software for working out the kinematics and joint and movement
rates and accelerations

A good introduction is here:
https://en.wikipedia.org/wiki/Denavit–Hartenberg_parameters

If you google Denavit-Hartenburg you will find software to read this
description and to visualize it to a computer screen

The job then of supporting the full general case because one of software
integration, not inventing new methods

Think of apian spray machine where the paint nozzle must always be kept at
a fixed distance and angle from the car fender being sprayed and must
always move at a fixed rate measured tangent to the surface.  These spray
machine are made mostly of rotary joints were the servo motors are
controlled to a given angular rate.   A walking robot has the same
problem.  Its foot must stay on the ground while the robot translates in
the direction of motion.  The problem is common and open source solution
exist




>
-- 

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 12:35:40 Chris Albertson wrote:

> On Sun, Nov 6, 2016 at 1:14 AM, Gene Heskett  
wrote:
> >  My newest concern is the poor
> > bogomips I see in dmesg. Only 153 for all 4 cores. This machine has
> > 17682.
>
> In case you did not catch it, "bogomips" is short for "bogus MIPS". 
> In other words a worthless measurement pf speed.
> The processor used in the Pi 3 actually runs  at just a little over 1
> MIP per GHz (more or less.)
>
> If you are seeing poor performance with remote X11, I'd suspect poor
> network in performance.  The best networking performance will be to
> use a USB 1000 BaseT dongle You will not get full gigabit level
> performance but it will outperform the built-in 100 BaseT interface.  
>  Then make sure you have a gigabit switch going to the PC.   The
> advantage here is that you are NOT running an x-server on the Pi 3. 
> Any work you can off load from there Pi 3 is good.   Check memory
> usage using "top"
>
It seems to me, the best, cheap link would be to usb-2 to usb-2, which 
gives 480 megabits each way, at the expense of some latency. However, 
since the hal is running on the machine connected to the machinery, the 
latency would be visual, and I don't believe that an extra 20ms due to 
the physical links inherent latency would be a detectable problem.

The problem as I see it, is in telling the usb system its ok to have a 
std board socket at both ends of the link, and locating a short, as in 
6-8 inches, usb to usb cable.

> The Machine kit people (if I understand it correctly) are breaking up
> LinuxCNC to run as a set of independent processes that communicate
> with messages.If Im right then it looks like the goal might be to
> have the ability to run the GUI on a different computer then HAL. 
> This is the best design, not exporting the display, but the entire GUI
> program.

That make more sense to me than just exporting x commands to a different 
server.

Now, I've had some breakfast and went to the garage to check it for first 
impressions. But am back quickly, in severe back pain because I forgot 
to take the morning pills, so the gabapenten hasn't had time to work.

1. Mouse is swimming in very cold corn syrup, and speeding it up in the 
mouse prefs makes no difference.  Not a show stopper, but distracting.

2. Linuxcnc is just as slow at opening its screen, and eventually drawing 
the full lcnc screen there as it is here. 15+ seconds to a fully drawn 
display.

3. Running the LinuxCNC logo, it ran normally.  Mouse no slower when lcnc 
is running, so this is AFAIAC a mouse problem in x. Running the same 
mouse/kbd on the Dell I disconnected, the mouse was best described as 
spastic, is now smooth and noticeably slow moving.  Microsoft kbd and 
mouse, and kbd known to not send timely keyup's. I'll check for weak 
batteries but the real fix for that keyboard is a logitech K-360 as the 
range to the dongle is way too short too. 3 feet max, <1 foot for no 
missed keys.

I should get some bi-color leds, steering diodes and some suitable 
current limiting R's and put them where the motors hook up so I can see 
the motors "running" while its sitting on the table yet.  That, and get 
the encoder finished.

I'm still debating on how to best get the encoders cable out of the 
spindle casting tub. Too much oil if I run it under the gears to one of 
2 holes in the rear of the tub. And potentially too close to spinning 
gears. One thought is to drill a hole near the lower front, tipping the 
drill as I go so a hunk of 3/8" SS tubing can be cut so as to drop thru 
the casting and down thru the standoff spacer bar where the QCGB used to 
be. That SS tubing is tough stuff, and cannot be bent by my tubing 
bender intended for similarly sized copper. That casting is also hard 
drilling, needing drill bits fresh from a drill doctor.

4. I get the impression the thing might work, if the mouse moved like my 
hand. That slow, laggy move is distracting.  The real test is how long 
from a gnd short on e-stop to a full machine stopped, not counting 
spindle unwind.

Question, how much memory have most reserved for the GPU? I set that up 
to 256 megs, from 64 in raspi-config, but that now seems excessive, 
could that be part of the mouse lag?

Now, maybe the %$# pill has become effective enough to walk around.

Datapoint on the synaptic run refusal, there was no passwd set for root, 
so I set one about 30 chars long.  Now it runs if I give it that passwd, 
but its almost unusable, wrong screen colors, mostly black, but fonts a 
tad big. Sub-windows it opens are transparent black, with data from the 
window under them showing thru.  Just barely usable IOW.

I haven't looked for an xconfigurator, but it looks like an 8 color, with 
4 of them solid black, screen. Best description is UGLY.

Cheers Chris, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt 

Re: [Emc-users] max_velocity during execution - multiple axis

[andy pugh]

On 6 November 2016 at 20:09, Danny Miller  wrote:
> Huh, ok, yeah inverse-time does make sense.

A little less sense than not-inverse time. In my opinion.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Danny Miller]

On 11/6/2016 1:57 PM, Robert Ellenberg wrote:
> On Sun, Nov 6, 2016 at 2:46 PM Danny Miller  wrote:
>
>> I did some rotary stuff on Mach3 and was baffled by similar issues.
>>
>> Seems like it'd be CAM's job to manage the feedrate, and calculate for
>> the work radius.  That would make sense if you were cutting a cylinder
>> and the G-code move was "X moves 3 inches, A rotates 100 times, feed X
>> at 1.5 inches/min"
>>
>> But if the cartesians aren't moving- which is common- the F value has no
>> meaning at all if it's cartesian.  There is no way for G-code language
>> to communicate "polar Feed =  200 deg/sec" and it's nonsense to combine
>> polar and cartesian vectors into a single scalar for a feedrate.
>>
> The F word is overloaded. If there's no cartesian motion, then it treats
> the number as degrees per min instead of in per min.
That sounds like a bad idea.  The interp of F jumps around to a totally 
different thing if there's no cartesian motion?
So if you MDI in  "G1 X1 A200 F3" it does one thing if you're at X=2 and 
a totally different thing if you're at X=1?  Or does the inclusion of 
any linear axis mode it over to cartesian?  Well, but, you couldn't do 
that- if you're already at X=1, F3 is all polar and it's impossible to 
interpret as a linear feedrate since there's no linear motion.

What if X moves 0.001" and that gets optimized out?
>
> Seems like the logical answer is amending G-code Feedrate with syntax
>> for an angular vector in addition to cartesian, but no CAM pkg would
>> support it.
>
> The "proper" way as I understand it is to use inverse time when doing both
> linear and angular moves. It's perfectly sensible to say "move X inches and
> A degress within T seconds".

Huh, ok, yeah inverse-time does make sense.
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

On Sun, Nov 6, 2016 at 2:46 PM Danny Miller  wrote:

> I did some rotary stuff on Mach3 and was baffled by similar issues.
>
> Seems like it'd be CAM's job to manage the feedrate, and calculate for
> the work radius.  That would make sense if you were cutting a cylinder
> and the G-code move was "X moves 3 inches, A rotates 100 times, feed X
> at 1.5 inches/min"
>
> But if the cartesians aren't moving- which is common- the F value has no
> meaning at all if it's cartesian.  There is no way for G-code language
> to communicate "polar Feed =  200 deg/sec" and it's nonsense to combine
> polar and cartesian vectors into a single scalar for a feedrate.
>

The F word is overloaded. If there's no cartesian motion, then it treats
the number as degrees per min instead of in per min.

Seems like the logical answer is amending G-code Feedrate with syntax
> for an angular vector in addition to cartesian, but no CAM pkg would
> support it.


The "proper" way as I understand it is to use inverse time when doing both
linear and angular moves. It's perfectly sensible to say "move X inches and
A degress within T seconds".
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Danny Miller]

I did some rotary stuff on Mach3 and was baffled by similar issues.

Seems like it'd be CAM's job to manage the feedrate, and calculate for 
the work radius.  That would make sense if you were cutting a cylinder 
and the G-code move was "X moves 3 inches, A rotates 100 times, feed X 
at 1.5 inches/min"

But if the cartesians aren't moving- which is common- the F value has no 
meaning at all if it's cartesian.  There is no way for G-code language 
to communicate "polar Feed =  200 deg/sec" and it's nonsense to combine 
polar and cartesian vectors into a single scalar for a feedrate.

Seems like the logical answer is amending G-code Feedrate with syntax 
for an angular vector in addition to cartesian, but no CAM pkg would 
support it.

Then again, the alternative is soft-declaring an axis and calculating 
surface speed and interpret the F as surface speed. Which would also not 
be supported by CAM AFAIK.  Well how DO commercial 4/5 axis CAM tools 
declare feedrates?   I presume they have a solution, as the tech's been 
in wide commercial use for a long time.

Danny


On 11/6/2016 11:48 AM, Robert Ellenberg wrote:
> As of now, circular arc blending doesn't work with the ABC axes (which is
> why it's running so slowly for you with short segments), but I'm working on
> a fix. I had an extensive discussion with Andy Pugh a while back, which led
> to some great ideas on how to solve this problem. There are two big reasons
> it doesn't work now:
>
> 1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
> spherical arc doesn't make physical sense between axes of different units.
>
> 2) "Velocity" as defined by the TP is actually velocity in either XYZ, ABC,
> or UVW axes, depending on the context, but a spherical arc in general would
> involve change in all 9 axes, so the arc length (and it's derivatives, TP
> velocity and acceleration) needs to be expressed in terms of all axes.
>
> What I'm working on now is to treat ABC axis motion as an equivalent tool
> tip motion in distance units. For example, if the tool is 10 inches above
> the physical A axis, then the A axis has an effective radius of 10 inches.
> Therefore it's easy to convert the angular motion to an equivalent tool top
> motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2 *
> 10 ~= 15.71 in.
>
> The good news is, if we assume some constant effective radius for all ABC
> axes, I think it's possible to implement with the same basic structures as
> the ones in my my experimental UVW axes blending branch
> 
> .
>
> The hard part is making the effective radius change with tool tip position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>
> Best,
> Rob
>
> On Sun, Nov 6, 2016 at 10:51 AM Tomaz T.  wrote:
>
> So for now there is no solution to speed this up till TP will be modified
> in the way that it will take and "optimize" also moves with rotary axis ...?
>
>
> PS. yes I'm from Slovenia.
>
>
> 
> From: klemenzivko...@gmail.com  on behalf of
> Klemen Zivkovic 
> Sent: Sunday, November 6, 2016 2:10 PM
> To: tomaz_...@hotmail.com
> Subject: [Emc-users] max_velocity during execution - multiple axis
>
> Hello,
>
>
> I think your problem is that linuxcnc have x,y,z trajectory planning. As
> soon as you add rotary axis to have combined move you end up with single
> lookahead in tp, so this limits velocity.
> Check this out:
> https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis
>
>
> According to your name - I need to ask you are you native slovenian speaker?
>
>
> regards
> KLemen
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi 

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

In the most general case, you're correct that the tool tip motion is a
function of the machine geometry. Putting it more succinctly, the tool tip
position (world space) is a nonlinear function of the joint positions. In
the general case, a linear motion in world space is not necessarily linear
in joint space. This non-linearity has all kinds of consequences for motion
planning:

   - Joint space limits are not prismatic (i.e. constant limits for every
   joint). Therefore, you can't be sure that a linear move is within joint
   space limits just because the end points are.
   - Joint space velocity is not proportional to tool tip velocity, and in
   general will change as a function of position. Therefore the max velocity /
   acceleration is not constant within a motion segment.

The current TP / motion planning architecture is really designed for
linear, orthogonal kinematics. There's been discussion about the necessary
redesign before (see here
).

So, what we can realistically do in the short term is chip away at the
problem:

   1. Get ABC blending working with a constant effective radius (i.e. some
   fixed conversion from degrees to inches)
   2. Make the effective radius specific to each motion segment, assuming
   each of the ABC axis have a fixed global orientation and origin.

I'm working on (1), and I have a plan for (2).

-Rob

On Sun, Nov 6, 2016 at 1:47 PM Klemen Živkovič 
wrote:

It seems that real motion and speeds are to be viewed from workpiece
coordinate system since one of the main requirements in CNC is to have
constant speed of tool over surface.
Also there is a need to somehow define generic way of calculating real
workpiece coordinates from dX,  dY, dZ and dA, dB, dC dU, dV, dW since
linuxcnc could not know,
what is machine geometry or tool movement dependency on different axis.

Since change A,B,C and U,V,W axes each separately or in combination result
in X,Y,Z movement
would it be possible to put in INI a math expression that would be kind of:

X(dA;dB;dC;dU,dV,dW) = dX + [name of radius A pin] * sin(dA*PI/180) + [name
of radius A pin] * cos(dA*PI/180) + ... (formulas of X dependency from
other axes) ...
Y(dA;dB;dC;dU,dV,dW) = 0
Z(dA;dB;dC;dU,dV,dW) = dZ + [name of radius A pin] * cos(dA*PI/180) + [name
of radius A pin] * sin(dA*PI/180) + ... (formulas of Z dependency from
other axes) ...

final movement would be then

Xnew = X_from_queue + X(dA;dB;dC;dU,dV,dW)
and similar for Y and Z axis.

In this way user could define dependencies of main cartesian axes XYZ from
angular ABC or linear UVW axis.

It seems that would require adding some symbolic computation library...
(check
http://stackoverflow.com/questions/11715162/symbolic-computation-library-in-pure-c
).

I hope I am not too much off topic and ideas are not too extreme to
implement.
Also if this is to be part of kinematics module of lcnc please somebody
correct me or direct me how this is to be aproached...





On Sun, Nov 6, 2016 at 6:48 PM, Robert Ellenberg  wrote:

> As of now, circular arc blending doesn't work with the ABC axes (which is
> why it's running so slowly for you with short segments), but I'm working
on
> a fix. I had an extensive discussion with Andy Pugh a while back, which
led
> to some great ideas on how to solve this problem. There are two big
reasons
> it doesn't work now:
>
> 1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
> spherical arc doesn't make physical sense between axes of different units.
>
> 2) "Velocity" as defined by the TP is actually velocity in either XYZ,
ABC,
> or UVW axes, depending on the context, but a spherical arc in general
would
> involve change in all 9 axes, so the arc length (and it's derivatives, TP
> velocity and acceleration) needs to be expressed in terms of all axes.
>
> What I'm working on now is to treat ABC axis motion as an equivalent tool
> tip motion in distance units. For example, if the tool is 10 inches above
> the physical A axis, then the A axis has an effective radius of 10 inches.
> Therefore it's easy to convert the angular motion to an equivalent tool
top
> motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2
*
> 10 ~= 15.71 in.
>
> The good news is, if we assume some constant effective radius for all ABC
> axes, I think it's possible to implement with the same basic structures as
> the ones in my my experimental UVW axes blending branch
>  tree/feature/uvw-blending-dev>
> .
>
> The hard part is making the effective radius change with tool tip
position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>
> Best,
> Rob
>
> On Sun, Nov 6, 2016 at 10:51 AM Tomaz T.  wrote:
>
> So for now there is no solution to speed this up till TP will be modified
> in the way that it 

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

It seems that real motion and speeds are to be viewed from workpiece
coordinate system since one of the main requirements in CNC is to have
constant speed of tool over surface.
Also there is a need to somehow define generic way of calculating real
workpiece coordinates from dX,  dY, dZ and dA, dB, dC dU, dV, dW since
linuxcnc could not know,
what is machine geometry or tool movement dependency on different axis.

Since change A,B,C and U,V,W axes each separately or in combination result
in X,Y,Z movement
would it be possible to put in INI a math expression that would be kind of:

X(dA;dB;dC;dU,dV,dW) = dX + [name of radius A pin] * sin(dA*PI/180) + [name
of radius A pin] * cos(dA*PI/180) + ... (formulas of X dependency from
other axes) ...
Y(dA;dB;dC;dU,dV,dW) = 0
Z(dA;dB;dC;dU,dV,dW) = dZ + [name of radius A pin] * cos(dA*PI/180) + [name
of radius A pin] * sin(dA*PI/180) + ... (formulas of Z dependency from
other axes) ...

final movement would be then

Xnew = X_from_queue + X(dA;dB;dC;dU,dV,dW)
and similar for Y and Z axis.

In this way user could define dependencies of main cartesian axes XYZ from
angular ABC or linear UVW axis.

It seems that would require adding some symbolic computation library...
(check
http://stackoverflow.com/questions/11715162/symbolic-computation-library-in-pure-c
).

I hope I am not too much off topic and ideas are not too extreme to
implement.
Also if this is to be part of kinematics module of lcnc please somebody
correct me or direct me how this is to be aproached...





On Sun, Nov 6, 2016 at 6:48 PM, Robert Ellenberg  wrote:

> As of now, circular arc blending doesn't work with the ABC axes (which is
> why it's running so slowly for you with short segments), but I'm working on
> a fix. I had an extensive discussion with Andy Pugh a while back, which led
> to some great ideas on how to solve this problem. There are two big reasons
> it doesn't work now:
>
> 1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
> spherical arc doesn't make physical sense between axes of different units.
>
> 2) "Velocity" as defined by the TP is actually velocity in either XYZ, ABC,
> or UVW axes, depending on the context, but a spherical arc in general would
> involve change in all 9 axes, so the arc length (and it's derivatives, TP
> velocity and acceleration) needs to be expressed in terms of all axes.
>
> What I'm working on now is to treat ABC axis motion as an equivalent tool
> tip motion in distance units. For example, if the tool is 10 inches above
> the physical A axis, then the A axis has an effective radius of 10 inches.
> Therefore it's easy to convert the angular motion to an equivalent tool top
> motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2 *
> 10 ~= 15.71 in.
>
> The good news is, if we assume some constant effective radius for all ABC
> axes, I think it's possible to implement with the same basic structures as
> the ones in my my experimental UVW axes blending branch
>  tree/feature/uvw-blending-dev>
> .
>
> The hard part is making the effective radius change with tool tip position.
> That's my long-term goal with this fix, but it may still be a big
> improvement to assume a constant effective radius.
>
> Best,
> Rob
>
> On Sun, Nov 6, 2016 at 10:51 AM Tomaz T.  wrote:
>
> So for now there is no solution to speed this up till TP will be modified
> in the way that it will take and "optimize" also moves with rotary axis
> ...?
>
>
> PS. yes I'm from Slovenia.
>
>
> 
> From: klemenzivko...@gmail.com  on behalf of
> Klemen Zivkovic 
> Sent: Sunday, November 6, 2016 2:10 PM
> To: tomaz_...@hotmail.com
> Subject: [Emc-users] max_velocity during execution - multiple axis
>
> Hello,
>
>
> I think your problem is that linuxcnc have x,y,z trajectory planning. As
> soon as you add rotary axis to have combined move you end up with single
> lookahead in tp, so this limits velocity.
> Check this out:
> https://forum.linuxcnc.org/20-g-code/29662-coordinated-
> motion-involving-rotary-axis
>
>
> According to your name - I need to ask you are you native slovenian
> speaker?
>
>
> regards
> KLemen
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi 

Re: [Emc-users] max_velocity during execution - multiple axis

[Robert Ellenberg]

As of now, circular arc blending doesn't work with the ABC axes (which is
why it's running so slowly for you with short segments), but I'm working on
a fix. I had an extensive discussion with Andy Pugh a while back, which led
to some great ideas on how to solve this problem. There are two big reasons
it doesn't work now:

1) ABC units are degrees, whereas linear axes (XYZUVW) are in distance. A
spherical arc doesn't make physical sense between axes of different units.

2) "Velocity" as defined by the TP is actually velocity in either XYZ, ABC,
or UVW axes, depending on the context, but a spherical arc in general would
involve change in all 9 axes, so the arc length (and it's derivatives, TP
velocity and acceleration) needs to be expressed in terms of all axes.

What I'm working on now is to treat ABC axis motion as an equivalent tool
tip motion in distance units. For example, if the tool is 10 inches above
the physical A axis, then the A axis has an effective radius of 10 inches.
Therefore it's easy to convert the angular motion to an equivalent tool top
motion. Ex: a 90 deg rotation would be similar to a linear move of pi / 2 *
10 ~= 15.71 in.

The good news is, if we assume some constant effective radius for all ABC
axes, I think it's possible to implement with the same basic structures as
the ones in my my experimental UVW axes blending branch

.

The hard part is making the effective radius change with tool tip position.
That's my long-term goal with this fix, but it may still be a big
improvement to assume a constant effective radius.

Best,
Rob

On Sun, Nov 6, 2016 at 10:51 AM Tomaz T.  wrote:

So for now there is no solution to speed this up till TP will be modified
in the way that it will take and "optimize" also moves with rotary axis ...?


PS. yes I'm from Slovenia.



From: klemenzivko...@gmail.com  on behalf of
Klemen Zivkovic 
Sent: Sunday, November 6, 2016 2:10 PM
To: tomaz_...@hotmail.com
Subject: [Emc-users] max_velocity during execution - multiple axis

Hello,


I think your problem is that linuxcnc have x,y,z trajectory planning. As
soon as you add rotary axis to have combined move you end up with single
lookahead in tp, so this limits velocity.
Check this out:
https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis


According to your name - I need to ask you are you native slovenian speaker?


regards
KLemen
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Chris Albertson]

On Sun, Nov 6, 2016 at 1:14 AM, Gene Heskett  wrote:

>
>  My newest concern is the poor
> bogomips I see in dmesg. Only 153 for all 4 cores. This machine has
> 17682.


In case you did not catch it, "bogomips" is short for "bogus MIPS".  In
other words a worthless measurement pf speed.
The processor used in the Pi 3 actually runs  at just a little over 1 MIP
per GHz (more or less.)

If you are seeing poor performance with remote X11, I'd suspect poor
network in performance.  The best networking performance will be to use a
USB 1000 BaseT dongle You will not get full gigabit level performance but
it will outperform the built-in 100 BaseT interface.Then make sure you
have a gigabit switch going to the PC.   The advantage here is that you are
NOT running an x-server on the Pi 3.  Any work you can off load from there
Pi 3 is good.   Check memory usage using "top"

The Machine kit people (if I understand it correctly) are breaking up
LinuxCNC to run as a set of independent processes that communicate with
messages.If Im right then it looks like the goal might be to have the
ability to run the GUI on a different computer then HAL.  This is the best
design, not exporting the display, but the entire GUI program.

Chris Albertson
Redondo Beach, California
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 11:51:02 Mark wrote:

> On 11/06/2016 11:03 AM, Gene Heskett wrote:
> > On Sunday 06 November 2016 06:43:21 W. Martinjak wrote:
> >> sudo dpkg-reconfigure locales
> >
> > This I have tried, at least 3 times. It goes thru the motions and
> > hand waving to set $LC to en_US.UTF-8, but:
> >
> > gene@raspberrypi:/etc/pam.d $ sudo dpkg-reconfigure locales
> > Generating locales (this might take a while)...
> >en_US.UTF-8... done
> > Generation complete.
> > gene@raspberrypi:/etc/pam.d $ env
> > XDG_SESSION_ID=c5
> > TERM=xterm
> > SHELL=/bin/bash
> > SSH_CLIENT=192.168.71.3 51556 22
> > SSH_TTY=/dev/pts/1
> > USER=gene
> > LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd
> >=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42
> >:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj
> >=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*
> >.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:
> >*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.
> >xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*
> >.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;3
> >1:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=0
> >1;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bm
> >p=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*
> >.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01
> >;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2
> >v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:
> >*.mp4v=01;35:*.vob=01;3
>
>  
5:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
> > MAIL=/var/mail/gene
> > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/u
> >sr/local/games:/usr/games PWD=/etc/pam.d
> > LANG=en_US.UTF-8
> > SHLVL=1
> > HOME=/home/gene
> > LOGNAME=gene
> > SSH_CONNECTION=192.168.71.3 51556 192.168.71.100 22
> > XDG_RUNTIME_DIR=/run/user/1001
> > DISPLAY=localhost:11.0
> > _=/usr/bin/env
> > OLDPWD=/home/gene
> > gene@raspberrypi:/etc/pam.d $ echo $LC
> >
> > gene@raspberrypi:/etc/pam.d $
> >
> > It is not set.  So:
> > gene@raspberrypi:/etc/pam.d $ sudo  export LC=en_US.UTF-8
> > sudo: export: command not found
> > Which would seem to explain that, but where the heck did export get
> > off to?
> >
> > raspian gets stranger and stranger.  It will not let me run
> > synaptic-pkexec either, returning this for anything I put in for my
> > sudo passwd:
> > gene@raspberrypi:/etc/pam.d $ synaptic-pkexec
> >  AUTHENTICATING FOR com.ubuntu.pkexec.synaptic ===
> > Authentication is required to run the Synaptic Package Manager
> > Authenticating as: root
> > Password:
> > polkit-agent-helper-1: pam_authenticate failed: Authentication
> > failure  AUTHENTICATION FAILED ===
> > Error executing command as another user: Not authorized
> >
> > This incident has been reported.
> >
> > That works perfectly on the other 5 x86 boxes here. So no gui
> > package manager is available on the pi so far.
> >
> > Yeah, I think aptitude may be installed, but I won't touch that with
> > a 20 foot fiberglass pole, its cost me too damned many reinstalls to
> > recover from its wanton scribbling over good stuff.  Last time I ran
> > it, to remove network-mangler, it did not warn me that it was going
> > to remove 388 other packages as dependencies. But I sure realized
> > that was a mistake as I watched it rip the heart out of my system. 
> > So that POS is not going to get a chance to burn me again, ever.
> >
> > Sorry Matsche, but even spelling that command on a keyboard makes me
> > overheat.
> >
> > So lets see if we can find out where export got lost?
> >
> > One last silly Q, if this hasn't the iron to run x and lcnc, I still
> > have an orange-pi-3 on a junk someplace in the big pond.  Would it
> > be possible to export the x stuff to it as a display device for
> > running LCNC? I still have room for it on the lid of this box.  Sort
> > of a miniature cloud?  Or is this dirt no one was walked on yet?
> >
> > Cheers Matsche, Gene Heskett
>
> You want the "export" to work under *your* shell.  Try the line
> without the "sudo."  What shell are you running under?  #echo $shell? 
/bin/bash
> Export is part of the bash/sh.  It'snot a standalone command.

My bad, I had forgotten that.  Can I blame oldtimers?
>
> The "synaptic-pkexec" is looking for the root password, not your sudo
> passwordwhen you run it that way.  Have you tried sudo
> synaptic-pkexec? You 

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 07:30:18 Erik Christiansen wrote:

> On 06.11.16 04:14, Gene Heskett wrote:
> > Did that already, Rainer. From an htop report, its currently sitting
> > at the pre-x login screen, gtk-greeter. My newest concern is the
> > poor bogomips I see in dmesg. Only 153 for all 4 cores. This machine
> > has 17682.  There may not be enough cycles to run x and linuxcnc.
>
> That's entirely possible, Gene. It seems unlikely that it will be even
> remotely real-time with a bit of X working, if this performance
> comparison is any guide:
>
> https://www.youtube.com/watch?v=dJkHxDjFuNA
>
> Mind you, I have an example of the compared board on order, and it is
> a long time coming. (I think they are accumulating sufficient orders
> to do another production run, given the delay.) The udoo board has no
> parport, but 20 GPIOs, so a parport ought to be synthesisable. Andy
> had a look at using the additional on-board ARM chip for the I/O, but
> posted that the CPU-CPU interface lacked appeal. (I suspect that might
> be because it's USB, which isn't anywhere near microsecond-splitting
> real-time. Pity.)
>
> My conversations with the Udoo people reveal that the X86 is built to
> boot almost any linux distro off SD card or flash stick, so running
> LinuxCNC should be a doddle. (But my first one is slated for video
> streaming, i.e. replace my desktop with a little 12v box. So I went
> for the middle performance one.)
>
> This page describes the sluggish performance of all the Rpis, even the
> pi3, showing a test tabulation giving the pi3 1/10th of the udoo X86's
> result: (Skip to 1:40 in the clip, to avoid a load of boring intro
> rubbish.)
>
> https://www.youtube.com/watch?v=_U2dlIEFBJI
>
> Erik
>
Most interesting, and reasonably priced too at $29 for the full pine-64 
monty. But it reads like video is its main hurrah.  Which is why I am 
curious if the orange-pi could offload the video duty's from the 
R-Pi-3b. I have a usb<->ethernet gismo, so there is the potential 
linkage path.

The udoo board is also interesting, and when compared to the total cost 
and real estate occupied by a pair of pi's by the time space is 
allocated for interconnections, possibly the better board.  But I should 
have the orange-pi-3 in another 2 weeks, if I can stand the wait. I 
don't find the 4k hdmi touted on some of these as a advantage due to the 
cost and non-ready availability of monitors for that format yet.

I just checked the tracking, and its getting closer, it was in a Noo 
Joisey USPO this morning.  Next week I expect. :)

Thanks Erik.  

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Mark]

On 11/06/2016 11:03 AM, Gene Heskett wrote:
> On Sunday 06 November 2016 06:43:21 W. Martinjak wrote:
>
>> sudo dpkg-reconfigure locales
> This I have tried, at least 3 times. It goes thru the motions and hand
> waving to set $LC to en_US.UTF-8, but:
>
> gene@raspberrypi:/etc/pam.d $ sudo dpkg-reconfigure locales
> Generating locales (this might take a while)...
>en_US.UTF-8... done
> Generation complete.
> gene@raspberrypi:/etc/pam.d $ env
> XDG_SESSION_ID=c5
> TERM=xterm
> SHELL=/bin/bash
> SSH_CLIENT=192.168.71.3 51556 22
> SSH_TTY=/dev/pts/1
> USER=gene
> LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=0
 
1;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
> MAIL=/var/mail/gene
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
> PWD=/etc/pam.d
> LANG=en_US.UTF-8
> SHLVL=1
> HOME=/home/gene
> LOGNAME=gene
> SSH_CONNECTION=192.168.71.3 51556 192.168.71.100 22
> XDG_RUNTIME_DIR=/run/user/1001
> DISPLAY=localhost:11.0
> _=/usr/bin/env
> OLDPWD=/home/gene
> gene@raspberrypi:/etc/pam.d $ echo $LC
>
> gene@raspberrypi:/etc/pam.d $
>
> It is not set.  So:
> gene@raspberrypi:/etc/pam.d $ sudo  export LC=en_US.UTF-8
> sudo: export: command not found
> Which would seem to explain that, but where the heck did export get off
> to?
>
> raspian gets stranger and stranger.  It will not let me run
> synaptic-pkexec either, returning this for anything I put in for my sudo
> passwd:
> gene@raspberrypi:/etc/pam.d $ synaptic-pkexec
>  AUTHENTICATING FOR com.ubuntu.pkexec.synaptic ===
> Authentication is required to run the Synaptic Package Manager
> Authenticating as: root
> Password:
> polkit-agent-helper-1: pam_authenticate failed: Authentication failure
>  AUTHENTICATION FAILED ===
> Error executing command as another user: Not authorized
>
> This incident has been reported.
>
> That works perfectly on the other 5 x86 boxes here. So no gui package
> manager is available on the pi so far.
>
> Yeah, I think aptitude may be installed, but I won't touch that with a 20
> foot fiberglass pole, its cost me too damned many reinstalls to recover
> from its wanton scribbling over good stuff.  Last time I ran it, to
> remove network-mangler, it did not warn me that it was going to remove
> 388 other packages as dependencies. But I sure realized that was a
> mistake as I watched it rip the heart out of my system.  So that POS is
> not going to get a chance to burn me again, ever.
>
> Sorry Matsche, but even spelling that command on a keyboard makes me
> overheat.
>
> So lets see if we can find out where export got lost?
>
> One last silly Q, if this hasn't the iron to run x and lcnc, I still have
> an orange-pi-3 on a junk someplace in the big pond.  Would it be
> possible to export the x stuff to it as a display device for running
> LCNC? I still have room for it on the lid of this box.  Sort of a
> miniature cloud?  Or is this dirt no one was walked on yet?
>
> Cheers Matsche, Gene Heskett

You want the "export" to work under *your* shell.  Try the line without 
the "sudo."  What shell are you running under?  #echo $shell?  Export is 
part of the bash/sh.  It'snot a standalone command.


The "synaptic-pkexec" is looking for the root password, not your sudo 
passwordwhen you run it that way.  Have you tried sudo synaptic-pkexec?  
You may have to edit /etc/sudoers to give your account the privs to be 
able to run those commands.


Mark



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel 

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 06:43:21 W. Martinjak wrote:

> sudo dpkg-reconfigure locales

This I have tried, at least 3 times. It goes thru the motions and hand 
waving to set $LC to en_US.UTF-8, but:

gene@raspberrypi:/etc/pam.d $ sudo dpkg-reconfigure locales
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
gene@raspberrypi:/etc/pam.d $ env
XDG_SESSION_ID=c5
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.71.3 51556 22
SSH_TTY=/dev/pts/1
USER=gene
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;
 
35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
MAIL=/var/mail/gene
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
PWD=/etc/pam.d
LANG=en_US.UTF-8
SHLVL=1
HOME=/home/gene
LOGNAME=gene
SSH_CONNECTION=192.168.71.3 51556 192.168.71.100 22
XDG_RUNTIME_DIR=/run/user/1001
DISPLAY=localhost:11.0
_=/usr/bin/env
OLDPWD=/home/gene
gene@raspberrypi:/etc/pam.d $ echo $LC

gene@raspberrypi:/etc/pam.d $ 

It is not set.  So:
gene@raspberrypi:/etc/pam.d $ sudo  export LC=en_US.UTF-8
sudo: export: command not found
Which would seem to explain that, but where the heck did export get off 
to?

raspian gets stranger and stranger.  It will not let me run 
synaptic-pkexec either, returning this for anything I put in for my sudo 
passwd:
gene@raspberrypi:/etc/pam.d $ synaptic-pkexec 
 AUTHENTICATING FOR com.ubuntu.pkexec.synaptic ===
Authentication is required to run the Synaptic Package Manager
Authenticating as: root
Password: 
polkit-agent-helper-1: pam_authenticate failed: Authentication failure
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.

That works perfectly on the other 5 x86 boxes here. So no gui package 
manager is available on the pi so far.

Yeah, I think aptitude may be installed, but I won't touch that with a 20 
foot fiberglass pole, its cost me too damned many reinstalls to recover 
from its wanton scribbling over good stuff.  Last time I ran it, to 
remove network-mangler, it did not warn me that it was going to remove 
388 other packages as dependencies. But I sure realized that was a 
mistake as I watched it rip the heart out of my system.  So that POS is 
not going to get a chance to burn me again, ever.

Sorry Matsche, but even spelling that command on a keyboard makes me 
overheat.

So lets see if we can find out where export got lost?

One last silly Q, if this hasn't the iron to run x and lcnc, I still have 
an orange-pi-3 on a junk someplace in the big pond.  Would it be 
possible to export the x stuff to it as a display device for running 
LCNC? I still have room for it on the lid of this box.  Sort of a 
miniature cloud?  Or is this dirt no one was walked on yet?

Cheers Matsche, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Tomaz T .]

So for now there is no solution to speed this up till TP will be modified in 
the way that it will take and "optimize" also moves with rotary axis ...?


PS. yes I'm from Slovenia.



From: klemenzivko...@gmail.com  on behalf of Klemen 
Zivkovic 
Sent: Sunday, November 6, 2016 2:10 PM
To: tomaz_...@hotmail.com
Subject: [Emc-users] max_velocity during execution - multiple axis

Hello,


I think your problem is that linuxcnc have x,y,z trajectory planning. As soon 
as you add rotary axis to have combined move you end up with single lookahead 
in tp, so this limits velocity.
Check this out:
https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis


According to your name - I need to ask you are you native slovenian speaker?


regards
KLemen
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LinuxCNC meetup 2016 Stuttgart, Germany

[alex chiosso]

Hi Rene.

Where is the final location for the Meeting in Stuttgart?
Still in the same place of the previous meetings?

Regards

Alex Chiosso

On Wed, Nov 2, 2016 at 6:50 PM, Rene Hopf  wrote:

> Es wird wieder ein LinuxCNC Treffen in Stuttgart geben.
>
> Die termine gelten jeweils für das ganze Wochenende, Freitag-Sonntag.
> Terminfindung/Anmeldung hier: http://doodle.com/poll/w52962an5pxgatsi
>
> Looks like we're meeting again this year.
>
> The Dates in the doodle are for the weekend, Friday-Sunday.
> http://doodle.com/poll/w52962an5pxgatsi
>
> Previous events:
> 2013: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_
> Integrator_Meeting_2013_Germany
> 2014: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_
> Integrator_Meeting_2014_Germany
>
> We will bring a demo of STMBL: https://github.com/rene-dev/stmbl
>
> Rene
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] max_velocity during execution - multiple axis

[Klemen Živkovič]

I think it is quite similar issue like in:
https://forum.linuxcnc.org/20-g-code/29662-coordinated-motion-involving-rotary-axis


On Sun, Nov 6, 2016 at 2:59 PM, Tomaz T.  wrote:

> I'm doing some tests on sim.vismach.5axis running full 5-axis code
> (milling sphere with spiral tool path). I have entered max_velocity and
> max_acceleration for each axis same as I have on my real machine and also
> in TRAJ section. So, when I'm running code, machine (sim) it reaches only
> half of its max_velocity, and only thing that helps is to "insanely"
> increase max_acceleration for both angular axis.
>
> So why is there such a big difference, and what else could help to speed
> it up?
>
>
> If there is anyone interest to test this (in sim), here is code:
>
> https://dl.dropboxusercontent.com/u/11501489/5x-test02.ngc
>
>
> My INI settings for linear axis are:
>
> MAX_VELOCITY:   90
>
> MAX_ACCELERATION: 100
>
>
> and for angular axis:
>
> MAX_VELOCITY:   20
>
> MAX_ACCELERATION: 35
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] max_velocity during execution - multiple axis

[Tomaz T .]

I'm doing some tests on sim.vismach.5axis running full 5-axis code (milling 
sphere with spiral tool path). I have entered max_velocity and max_acceleration 
for each axis same as I have on my real machine and also in TRAJ section. So, 
when I'm running code, machine (sim) it reaches only half of its max_velocity, 
and only thing that helps is to "insanely" increase max_acceleration for both 
angular axis.

So why is there such a big difference, and what else could help to speed it up?


If there is anyone interest to test this (in sim), here is code:

https://dl.dropboxusercontent.com/u/11501489/5x-test02.ngc


My INI settings for linear axis are:

MAX_VELOCITY:   90

MAX_ACCELERATION: 100


and for angular axis:

MAX_VELOCITY:   20

MAX_ACCELERATION: 35
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Erik Christiansen]

On 06.11.16 04:14, Gene Heskett wrote:
> Did that already, Rainer. From an htop report, its currently sitting at 
> the pre-x login screen, gtk-greeter. My newest concern is the poor 
> bogomips I see in dmesg. Only 153 for all 4 cores. This machine has 
> 17682.  There may not be enough cycles to run x and linuxcnc.

That's entirely possible, Gene. It seems unlikely that it will be even
remotely real-time with a bit of X working, if this performance
comparison is any guide:

https://www.youtube.com/watch?v=dJkHxDjFuNA

Mind you, I have an example of the compared board on order, and it is a
long time coming. (I think they are accumulating sufficient orders to do
another production run, given the delay.) The udoo board has no parport,
but 20 GPIOs, so a parport ought to be synthesisable. Andy had a look at
using the additional on-board ARM chip for the I/O, but posted that the
CPU-CPU interface lacked appeal. (I suspect that might be because it's
USB, which isn't anywhere near microsecond-splitting real-time. Pity.)

My conversations with the Udoo people reveal that the X86 is built to
boot almost any linux distro off SD card or flash stick, so running
LinuxCNC should be a doddle. (But my first one is slated for video
streaming, i.e. replace my desktop with a little 12v box. So I went for
the middle performance one.)

This page describes the sluggish performance of all the Rpis, even the
pi3, showing a test tabulation giving the pi3 1/10th of the udoo X86's
result: (Skip to 1:40 in the clip, to avoid a load of boring intro rubbish.)

https://www.youtube.com/watch?v=_U2dlIEFBJI

Erik

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[W. Martinjak]

On 2016-11-06 04:34, Gene Heskett wrote:
> But $LC is still 
> missing from an env report  

sudo dpkg-reconfigure locales

-- 
"In der Wissenschaft siegt nie eine neue Theorie,
nur ihre Gegner sterben nach und nach"

Max Planck


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[W. Martinjak]

On 2016-11-06 10:14, Gene Heskett wrote:
> Did that already, Rainer. From an htop report, its currently sitting at 
> the pre-x login screen, gtk-greeter. My newest concern is the poor 
> bogomips I see in dmesg. Only 153 for all 4 cores. This machine has 
> 17682.  There may not be enough cycles to run x and linuxcnc.
>
> Its a question I'll see an answer to come a civilized time of day. 
> raspi-config already refused to overclock it, saying this model can't do 
> it.

That's why it's called "BogoMips" .

https://www.raspberrypi.org/forums/viewtopic.php?t=32975=282680



-- 
"In der Wissenschaft siegt nie eine neue Theorie,
nur ihre Gegner sterben nach und nach"

Max Planck


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Carousel component questions

[Jan Bos]

Thank you all for your feedback. As I expected, I will add the sensor and
give it a try.

I am following the 'VMV Hal related questions' thread on the forum and I
have the virtual machine working. This virtual set-up is very close to what
I want to achieve. I am hooking up the sensors now for the ATC and the
relays for the motor and then I will try to make stuff move. I do not need
spindle orientation since I have this in the VFD.

I am confident that I will be back for further help but for now, I have
work to do.

Thanks again!

JB

On Fri, Nov 4, 2016 at 11:50 PM, Kirk Wallace 
wrote:

> On 11/03/2016 06:23 PM, Jan Bos wrote:
> ...
> > Do I need to add a 'home' sensor or a 'pocket 1' sensor?
> >
> > I am not quite clear on how this is supposed to work, could anybody shine
> > some light on how the Carousel component works with sensor inputs like
> this?
> ...
>
> For reference, I don't use the carousel component but this is how my
> mill was set up:
> http://www.wallacecompany.com/tmp/Carousel_Position.png
>
> The chain has a foot mounted at the home position to activate the home
> switch. The pocket switch sensed when a pocket was in parked position. I
> seem to recall that the g-code called for X number of pockets forward or
> back, and did not keep track of pocket ID.
>
> (The Geneva has been replaced with direct drive and there is a position
> encoder on the carousel.)
>
> --
> Kirk Wallace
> http://www.wallacecompany.com/machine_shop/
> http://www.wallacecompany.com/E45/
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Fox Mulder]

Am 06.11.2016 um 00:20 schrieb Gene Heskett:
> My instant problem is that X is not running on the r-pi-3, so while I 
> have beautiful hires text screens, at least on the login screen, no x, 
> so linuxcnc cannot run.
> 
> Looking in /var/cache/apt/archives it does look like quite a bit of x is 
> installed.
> 
> Does anyone have some hints on how to bring up a working x on the r-pi-3 
> running linux?

In the tool "raspi-config" you can select the "Boot Options" and change
if it should start to console or the X11 gui after boot.

This tool has some more useful options specific for the rpi so just take
a look at the different menu entries. :)

Ciao,
 Rainer

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] X on pi-3?

[Gene Heskett]

On Sunday 06 November 2016 03:49:56 Fox Mulder wrote:

> Am 06.11.2016 um 00:20 schrieb Gene Heskett:
> > My instant problem is that X is not running on the r-pi-3, so while
> > I have beautiful hires text screens, at least on the login screen,
> > no x, so linuxcnc cannot run.
> >
> > Looking in /var/cache/apt/archives it does look like quite a bit of
> > x is installed.
> >
> > Does anyone have some hints on how to bring up a working x on the
> > r-pi-3 running linux?
>
> In the tool "raspi-config" you can select the "Boot Options" and
> change if it should start to console or the X11 gui after boot.
>
> This tool has some more useful options specific for the rpi so just
> take a look at the different menu entries. :)
>
> Ciao,
>  Rainer

Did that already, Rainer. From an htop report, its currently sitting at 
the pre-x login screen, gtk-greeter. My newest concern is the poor 
bogomips I see in dmesg. Only 153 for all 4 cores. This machine has 
17682.  There may not be enough cycles to run x and linuxcnc.

Its a question I'll see an answer to come a civilized time of day. 
raspi-config already refused to overclock it, saying this model can't do 
it.

Thanks Rainer.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] An observation on digital calipers

[Danny Miller]

I tried to buy a pair of HFT calipers a few years ago, found they didn't 
read right, lost large distances.

Went to exchange them but thought "hey let's make sure I get a pair that 
works..."

NONE OF THEM.  Went through like 10 boxes on the shelf.  None read 
correctly.

Now I've had an HFT I bought like 12 yrs ago that worked GREAT.

But, anyhow, Neiko calipers are just as cheap and work great now:

https://www.amazon.com/Neiko-01407A-Electronic-Digital-Caliper/dp/B000GSLKIW/ref=sr_1_1?ie=UTF8=1478415113=8-1=neiko

Danny

On 11/6/2016 12:01 AM, Chris Albertson wrote:
> On Tue, Nov 1, 2016 at 1:54 AM, andy pugh  wrote:
>
>> How cheap are HF?
>> http://www.machine-dro.co.uk/left-handed-digital-calipers-150mm-6.html
>
> HF sells the right hand version of that exact same caliper for $19 and they
> always have discount coupons.  I paid $15 for one.
>
> I've never had a problem with handedness, you can always flip them over,
> hold them upside down or whatever


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users