[Emc-developers] HUMM, good code won't run

2020-06-12 Thread Gene Heskett
Greetings all;

updated the master/wheezy on th G0704 earlier today, then opened up the 
nema 34 mount to pass the spindle end of a nema 23 motor.  I carved that 
square pattern without any hickups not of my doing, but that adapter 
plates boltholes for the nema 23 weren't tapped.

Saddled up and went to TSC where I took them out of 5x.8 x 10's and 12's 
cap screws.

Come back, load up lcnc and home it, put the head in low gear, and load 
the code below.

( tap5mmx.8mm pitch-hole.ngc )
( to tap the holes for screws in the saddle of the Sheldon or for any 5mm 
threaded hole)
( working in metric )
G21 g7 ( measure in mm's & diameter)
( setup a path for data from this file to hal, in this case the tpmm for 
g33.1's -kval)
#<_tpmm> = .800
#<_z_depth> = -10.00
#<_z_dec>   =   [ #<_z_depth> / 10]  ( go a bit farther each time)
(debug, z_dec=#<_z_dec>)
#<_z_tmp>   =   0.
G1 F750 z0.
( center at touched off x, don't touch Y )
S200 M3
o100 WHILE [#<_z_tmp> ge #<_z_depth>]
M68 E0 Q#<_tpmm>
G33.1 Z#<_z_tmp> k#<_tpmm>
#<_z_tmp>   =   [#<_z_tmp> + #<_z_dec>]
G4 P3 (3 second pause to blow chips & buttercut the tap )
o100 ENDWHILE
M5
G0 z75
M2
%

This code ran fine the last time I used it, but now a click on go starts 
the spindle, spindle-at-speed is solidly true, but it never execs the 
first of 10 loops. Nor does it highlight the problem line.
clues anybody, or a real bug?

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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


Re: [Emc-developers] 2.8 Situation

2020-06-12 Thread Bojan Topalovski
I loved this conversation... to much sparks..

On Fri, Jun 12, 2020, 18:23 Reinhard  wrote:

> Hi,
>
> On Freitag, 12. Juni 2020, 11:03:53 CEST andy pugh wrote:
> > A major release has a matching ISO file for a scratch install,
>
> that could be automated
>
> > is thought to be largely bug-free
>
> Hm, I guess, your entitlement on that item is too much.
>
> > and has documentation that matches the
> > actual behaviour.
>
> Whow - that never has been true - at least from my point of view.
> But may be I focus a different picture.
>
> Never mind - keep on rocking ;)
>
>
> cheers Reinhard
>
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


Re: [Emc-developers] 2.8 Situation

2020-06-12 Thread Reinhard
Hi,

On Freitag, 12. Juni 2020, 11:03:53 CEST andy pugh wrote:
> A major release has a matching ISO file for a scratch install, 

that could be automated

> is thought to be largely bug-free

Hm, I guess, your entitlement on that item is too much.

> and has documentation that matches the
> actual behaviour.

Whow - that never has been true - at least from my point of view.
But may be I focus a different picture.

Never mind - keep on rocking ;)


cheers Reinhard





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


Re: [Emc-developers] 2.8 Situation

2020-06-12 Thread Jon Elson

On 06/12/2020 04:03 AM, andy pugh wrote:
Machinekit abandoned the idea of releases. I have heard 
that that makes it hard to find a version that actually works.
Yes, my test fixture still uses a build set up by Matt 
Shaver quite a few years ago.


But, then, Robert C. Nelson started building Beagle Bone 
kernel releases with machinekit pre-installed.
I use these for a number of non-CNC projects, but also for 
at least one that does use the Machinekit variant of 
LinuxCNC for a one-axis positioner.  As far as I know, this 
is still being built and up to date, there are links on the 
Machinekit web pages for how to download the entire install 
with machinekit.


Jon


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


Re: [Emc-developers] 2.8 Situation

2020-06-12 Thread andy pugh
On Fri, 12 Jun 2020 at 04:28, Reinhard  wrote:

> So let's ask for the other side of view - what's the difference between a
> snapshot from master to a ordinally rolled out release - from the user side of
> view?
> Afaik all they want, are packages to install from without compiling.

A major release has a matching ISO file for a scratch install, is
thought to be largely bug-free and has documentation that matches the
actual behaviour.
At least in principle.

Machinekit abandoned the idea of releases. I have heard that that
makes it hard to find a version that actually works.

--
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, 1912


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


Re: [Emc-developers] 2.8 Situation

2020-06-12 Thread Gene Heskett
On Thursday 11 June 2020 23:28:26 Reinhard wrote:

> Hi Gene
>
> On Donnerstag, 11. Juni 2020, 21:53:55 CEST Gene Heskett wrote:
> > I find it totally unreal that most shop owners won't spend the
> > sheckles to buy a router and maybe a switch to put the network into
> > every machine in the building.  Security is in how you do it, and
> > I've not been touched in 20 some years.
>
> Yes, I know it the same way. Many shop owners have physically
> separated networks. That's not the question and no problem.
>
> > Yet I can update any machine on my locale network everytime the
> > buildbot makes a new version available  to apt or synaptic.
>
> I know you run a build farm. And I know the cost of a release from
> developer point of view.
>
> So let's ask for the other side of view - what's the difference
> between a snapshot from master to a ordinally rolled out release -
> from the user side of view?
> Afaik all they want, are packages to install from without compiling.
> So if the buildbot generates that packages, you could simply declare a
> snapshot to be a release. That would be a manageable job.
>
> But as I understand Andy, he does a lot of extra testing to deliver a
> pretty bugfree release. That's what I'm talking about and I think,
> that time could be better invested.
>
> > And I wouldn't have a milliseconds problem with an annual small fee
> > to pay for buildbot electricity and server bandwidth.
>
> I know - but users that think the same way as you don't cry for new
> versions or for many releases in short cycles.
> You help a lot to push the project ahead - so it wasn't you, that I
> was talking about.
>
I think of myself more as the canary in the coal mine, lightly exercising 
the buildbots output, occasionally even building my own armhf version 
via a git pull to check on things in the pi world.  And if my canary 
dies, reporting the failure ASAP.

Sometimes, I won't catalog, my reports have been fixed in a few hours.  
So thats my contribution to the stability of the code seen by the 
installers using a "release".  That is their choice. But its gaining new 
or better features they are missing out on too by sticking with a 
release.

But real brokeness, even in a production shop, will be found to not have, 
IMNSHO, a very serious effect on the bottom line by running master, it 
quite simply is not that broken for that long. If I was better at 
scripts, a daily git pull and build of the install debs on that armhf 
would be running.  With any failures generating an automatic email to 
raise and wave that famous hand.

What I need, since I've broken the git pull and build to the make tests 
stage, and a separate deb build is a way to condition the deb build on 
the results of the make tests.

Many thanks to Andy and probably others, LinuxCNC is likely the most 
tested software on the planet every time the buildbot makes a new 
master, with going on 250 "does it actually run right" tests of every 
function it has as part of the make tests at the end of my first script 
on the pi4b. I don't think new functions get added without a suitable 
test being written. On my pi, make tests takes more time to run than the 
actual build.

I don't think the huge majority of "release" users know or appreciate 
that.  The wiki maintainers are failing at their advertising efforts for 
not makeing that little detail a hell of a lot more promenant.

There is not an RTAI for armhf, so all my builds are for a preempt-rt 
kernel. I get latency overruns even with RTAI, on my wheezy builds, 
short enough the machine doesn't seem to notice, but I don't get any 
more running uspace on the pi4b either.  I've no clue about arm64 
builds. But I am running, other than kernel related stuffs, 6 packages 
its not updating of a 100% uptodate buster build from raspbian on that 
pi4b.

> cheers Reinhard
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers