from:"EBo"

Re: [Emc-developers] Stretch-based LinuxCNC images ready for testing

2017-07-21 Thread EBo


Tom,

If you delve into the implementation details you will come to 
understand that RT-Preempt (RTP)  will probably never have as good 
latency times as RTAI or RT-Linux (RTL) -- because RTAI/RTL run as 
dedicated TSR processes that sit above the OS if I remember correctly, 
whereas RTP is managed within the kernel itself.  That said, RTP is 
getting latencies down to the point that are good enough for most 
applications.  I guess what I am trying to say here is that if you focus 
on just the raw numbers it is easy to fall into the trap of perfection 
being the enemy of the good.


One other critical point for understanding why a lot of us want to see 
RTP support is that RTP is now incorporated within the Linux kernel 
source tree, and is supported/maintained by the kernel devs themselves.  
I doubt that RTAI or RTL ever will because they hijack a normal kernel.  
If you take a step back you will find that both RTAI and RTL support 
chooses a kernel version to hack, releases patches, and half the time 
they do not work with standard kernels.  This ends up locking us into 
very specific versions of the kernel, and is extremely fragile.  But by 
all means, run RTAI/RTL versions of the kernel for LCNC, but when you 
want to upgrade your kernel you are either going to have to wait around 
until someone with the skills and experience of kernel hacking dedicates 
their time on this, or you will have to do so yourself.


Hope this is helpful and does not start a flame-war.  I would love to 
see RTAI integrated into the kernel, but given how Linus and other devs 
feel about hard RT, I can only wish you luck with that.


  EBo --

On Jul 21 2017 9:01 AM, tom-...@bgp.nu wrote:

So if I am reading your message correctly, preempt’s latencies are
not typically as good as RTAI?  Will there be an RTAI kernel for
Stretch at some point?
Thanks,
-Tom

On Jul 21, 2017, at 8:25 AM, Jeff Epler <jep...@unpythonic.net> 
wrote:


I've been working on a live+install image of Debian Stretch with
* The just-released LinuxCNC 2.7.10
* kernel 4.9.0-3-rt-amd64 or 4.9.0-3-rt-686-pae
* xfce desktop (same desktop we used on wheezy)
* goodies like hostmot2 firmwares, truetype-tracer, f-engrave

This image is based on the "PREEMPT RT" kernel, which typically
gives latencies good enough for FPGA-based systems, though often the
latency is too high for software encoder and stepgen systems.
Assuming you have a multi-core system, isolating the highest
numbered CPU with isolcpus=# on the kernel commandline may help
latency, just as with RTAI.

Unless you know your computer only supports 32-bit code, I recommend
using the -amd64 image, which works for both AMD and Intel 64-bit
CPUs.

Like the older images, you can either boot live to test your
hardware, or install to the hard disk, from the same iso image.

The Debian image is a "hybrid" iso, which means you can use the same
iso file for a USB stick or a DVD.  (The image is bigger than a
traditional CD, so you can't install from regular CD anymore.)
Instructions for writing the image to a USB stick from Windows and
Linux are here:

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Hybrid_Iso

**NOTE** the Ubuntu "startup disk creator" and unetbootin do NOT
handle hybrid images.  Use the above instructions instead, if you
want to install from USB.  To install from DVD you can use any
traditional method to write the iso image.

You can find it at the temporary URL
http://www.linuxcnc.org/testing-stretch-rtpreempt/

For more notes and for the scripts used to build these images,
see https://github.com/jepler/stretch-live-build

The github repository has an "issues" section.  Please use it only
to file bugs about the image itself, not about bugs in LinuxCNC,
even if the bug in LinuxCNC seems to be specific to Debian Stretch.
(but if you aren't sure, then file it in stretch-live-build and
we'll triage it)

Jeff


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourc

Re: [Emc-developers] Fwd: Re: More better r-pi?

2017-07-14 Thread EBo


On Jul 14 2017 6:14 AM, Bertho Stultiens wrote:

On 07/14/2017 01:26 PM, andy pugh wrote:

Maybe some other developer can pitch in and say something about I/O
scheduling as currently implemented in LCNC?


EPP Parallel port works well for Pico and some Mesa cards. I don't
think IO data throughput is actually any real concern.


The throughput should be fine, but what about the latency?


Everything has latency.  The real question is if the latency of that 
device is sufficiently small for a particular application.


  EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Gremlin

2017-07-05 Thread EBo

Are you saying that you should not expose the code to water, expose it 
to sunlight, or feed it after dark? (hint: allusion to the 80's movie 
Gremlins)


On Jul 5 2017 1:50 PM, Kurt Jacobson wrote:

Oh dear Andy, you saw my gremlin hacking ;-)

It might be a good idea, but it was my first attempt at threading...
Need I say more?

Kurt

On Wed, Jul 5, 2017 at 3:09 PM, Sebastian Kuzminsky  
wrote:





On July 5, 2017 5:57:27 AM MDT, andy pugh  
wrote:

>An interesting idea here:
>https://forum.linuxcnc.org/41-guis/32678-hazzy-another-
touchscreen-gui?start=50#95287
>
>He is running the Gremlin backplot in a separate thread to allow 
you

>to home etc when the backplot is calculating.
>
>This does seem like a splendid idea

Sounds like a good idea to me too.

--
Sebastian Kuzminsky


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Finest resolution of Lcnc

2017-07-05 Thread EBo

Thank you BKT for your comments.  I had meant in my reply that it is in 
fact possible to build a conventional configured lathe which actually 
can routinely do the precision required for their application, and 
provide some idea of what you have to do to make this work in practice.  
You are right that it is difficult measuring anything at that precision.


On Jul 5 2017 1:23 AM, theman whosoldtheworld wrote:
For my little experience as insert for late and mill seller, some 
late for
bearing work with cheramic + diamond insert and air flow as 
lubrificant
 these means more or less 20° araund tool, araund bearing in 
working
order, plus in most cases machines equipped with oil coolers 
circulating
around the spindle and slides ... so most of the lathe concerned is 
kept at
a constant temperature ... so the hight precision is possible ... the 
most
problem regards the real measure ... if is right the working bearing 
is
kostant in measure, it is not so sure that the measure obtained is 
the
desired one ... in fact, it is very difficult to measure the 
spherical
bearing head ... beyond the only transfer from the working area to 
the

measuring chamber changes the measurement itself.
So you do not have to be amazed at the data you bring ... above all 
you

have to remember that data is collected in the field and not in the
measurement laboratories.

regards
bkt

2017-07-04 20:39 GMT+02:00 EBo <e...@sandien.com>:

I had studied the design specs for a lathe which was certified 
<0.02"
which used oil bearings instead of air, but from what I have seen 
1um is

reasonably doable by mere mortals <https://www.youtube.com/watch
?v=sFrVdoOhu1Q>, however back in the 90's there were only a handful 
of
people that could build, tune, and run a machine that would do 20x 
the
precision.  And yes, you have to temperature and hudity control the 
work
(unless the structural members of the machine are made from 
something like

Sitall or Zerodur...


On Jul 4 2017 11:05 AM, Marius Liebenberg wrote:


There are lathes that do that already. The lathe is temperature
controlled and the slides run on air bearings with a tolerance of
better than 2 or 3 nano meters. The job is given in 10 micron steps
and I have to work the gcode from there

-- Original Message --
From: "Niemand Sonst" <nie...@web.de>
To: emc-developers@lists.sourceforge.net
Sent: 2017-07-04 18:01:54
Subject: Re: [Emc-developers] Finest resolution of Lcnc

Gmoccapy is not the issue, as you can add more digits to the DRO on 
the
settings page. But if you speak about 0.1 µm it is useless to 
build a lathe

on that accuracy, as you will never be able to turn a part at that
accuracy. Just a few degrees temperature difference will destroy 
the

repeatability.

Just calculate 1 Degree is 1 µm length difference on every 100 mm.

Norbert

Am 04.07.2017 um 17:15 schrieb Marius Liebenberg:

The DRO's will have to be modified a bit I suppose. In order to 
show

the larger travels. The max travel is about 300mm.

-- Original Message --
From: "andy pugh" <bodge...@gmail.com>
To: "Marius Liebenberg" <mar...@mastercut.co.za>; "EMC 
developers" <

emc-developers@lists.sourceforge.net>
Sent: 2017-07-04 13:59:32
Subject: Re: [Emc-developers] Finest resolution of Lcnc

On 4 July 2017 at 12:10, Marius Liebenberg 
<mar...@mastercut.co.za>

wrote:

 The question I have is - will I be able to control the lathe to 
say

0.1
 micro meter with Lcnc using the Gmoccapy front end.



You could easily configure the machine to use microns as the 
base unit

(then G20 would work in thousandths of an inch).


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



---
This email has been checked for viruses by Avast antivirus 
software.

https://www.avast.com/antivirus

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers






--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link

Re: [Emc-developers] Finest resolution of Lcnc

2017-07-04 Thread EBo

I had studied the design specs for a lathe which was certified 
<0.02" which used oil bearings instead of air, but from what I have 
seen 1um is reasonably doable by mere mortals 
, however back in the 90's 
there were only a handful of people that could build, tune, and run a 
machine that would do 20x the precision.  And yes, you have to 
temperature and hudity control the work (unless the structural members 
of the machine are made from something like Sitall or Zerodur...


On Jul 4 2017 11:05 AM, Marius Liebenberg wrote:

There are lathes that do that already. The lathe is temperature
controlled and the slides run on air bearings with a tolerance of
better than 2 or 3 nano meters. The job is given in 10 micron steps
and I have to work the gcode from there

-- Original Message --
From: "Niemand Sonst" 
To: emc-developers@lists.sourceforge.net
Sent: 2017-07-04 18:01:54
Subject: Re: [Emc-developers] Finest resolution of Lcnc

Gmoccapy is not the issue, as you can add more digits to the DRO on 
the settings page. But if you speak about 0.1 µm it is useless to 
build a lathe on that accuracy, as you will never be able to turn a 
part at that accuracy. Just a few degrees temperature difference will 
destroy the repeatability.


Just calculate 1 Degree is 1 µm length difference on every 100 mm.

Norbert

Am 04.07.2017 um 17:15 schrieb Marius Liebenberg:
The DRO's will have to be modified a bit I suppose. In order to show 
the larger travels. The max travel is about 300mm.


-- Original Message --
From: "andy pugh" 
To: "Marius Liebenberg" ; "EMC developers" 


Sent: 2017-07-04 13:59:32
Subject: Re: [Emc-developers] Finest resolution of Lcnc

On 4 July 2017 at 12:10, Marius Liebenberg  
wrote:


 The question I have is - will I be able to control the lathe to 
say 0.1

 micro meter with Lcnc using the Gmoccapy front end.


You could easily configure the machine to use microns as the base 
unit

(then G20 would work in thousandths of an inch).


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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More RPI possibilities

2017-06-20 Thread EBo

On Jun 20 2017 1:26 PM, Bertho Stultiens wrote:

On 06/20/2017 07:38 PM, EBo wrote:
Well, SPI is now working and it seems to be satisfactory. I created
an
experimental EPP driver for the 7i90/7i43 (which is why I started
this

thread) but it needs to be tested and I am looking for volunteers.

What all would be evolved with testing? We found a use at work to
use
an RPi-3 for a proof of concept, so I will be jumping back into
RPi's

for the next while. It would be nice to make sure that the hard
real-time and other systems are running correctly, as well as LCNC.
I
also need to get back to some LCNC projects whenever I can break
away
the time... Anyway, I or my intern might take a poke at the testing
if

it does not envolve to much, or if we can find a way to make it work
related...

First thing you need is a quite a bit of patience. Creating bootable
images with all updates and extra packages RPi is a slow process on a
RPi. So you better have some other work too, or there cannot be
enough

coffee.

You need to build a converter from the 40-pin I/O header to a 26-pin
IDC

with flatcable (see http://media.vagrearg.org/rpi3-lcnc/pi-epp.pdf).

Now for the software.

The easy way gets you going, but there may be junk you do not
need/want

or care about or whatever brainfart I mistakenly left in that image.

The hard way will make you in full control of the image you create.
It

also ensures that you actually get an idea what you need to build and
run (I found that very helpful)

The "easy" way (couple of hours to start testing):
--
1 - Get my SD image.
It is a bit used, but it is fully functional.
This will take, no joke, about 3.14 hours to upload.
The image: picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
will be available from http://media.vagrearg.org/rpi3-lcnc/
(once it is uploaded)

sha256sum:
46f4ea007241274f879eb09142bf126ea3c32f5dbdd8488f0c9b1b4f43db79d1
picnc-rt_kernel-4.4.4-dev-lcnc-X-20170620210413.img.gz
size:
1629293657

2 - dd image to 8+GB SD card
3 - Copy a set of ini/hal files to ~/linuxcnc/configs/...
and modify them to use the new hm2_rpepp driver
4 - test

The "hard" way (about a day before testing):

1 - install base Raspbian image on 8+GB SD card

2 - update the image (atp-get update; apt-get dist-upgrade)

3 - install RT-PREEMPT kernel 4.4.4-rt9-v7+ from Machinekit
The procedure has been derived from
http://www.machinekit.io/docs/getting-started/install-rt-kernel-RPi2/
However, I did not want to upgrade the bootloader and that means
doing

more work. Please note that is will run properly on the Pi3. If you
upgrade the bootloader then disregard the following and keep to the
MK

described procedure.

Procedure without upgrading the bootloader:
$ sudo su -
# wget

http://deb.machinekit.io/debian/pool/main/l/linux-rt/linux-image-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# wget

http://deb.machinekit.io/debian/pool/main/l/linux-rt/linux-headers-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# dpkg -i linux-image-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
linux-headers-rpi2-rt_4.4.4-rt9-v7+-7_armhf.deb
# cd /boot
# mkdir old
# mv bcm* overlays kernel7.img old/
# mv dtbs_rt/* .
# cp kernel_rt-4.4.4-rt9-v7+.img kernel7.img
# sync

Now you have to edit /boot/cmdline.txt to look something like this:
dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 dwc_otg.nak_holdoff=0
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 root=PARTUUID=4fb6ef8f-02
rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

The first three parameters have been added. Your "root=..." and
"console=..." are probably different. I have a serial console
attached

for debug purpose.

4 - add to /etc/rc.local
echo -n 120 >
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq

echo -n performance >
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor

Finally, reboot.

5 - install git

6 - clone LinuxCNC from github. My fork has the hm2_rpepp module in a
branch called hm2_rpepp; see https://github.com/BsAtHome/linuxcnc

7 - brace yourself, about to install build-dependencies

8 - read docs/src/code/building-linuxcnc.txt how to find the build
dependencies. Basically:
$ sudo apt-get install dpkg-dev
$ cd ~linuxcnc-git/debian
$ ./configure uspace
$ cd ..
$ dpkg-checkbuilddeps

Now install all that has been listed and get some more coffee and
probably return the next morning.

9 - Build LinuxCNC. Beware: do _not_ compile with parallel jobs. The
RPi
has not enough memory to compile multiple c++ files and starts
swapping,

killing the performance and going to practically zero progress.
$ cd ~/linuxcnc-git/src
$ ./configure --with-realtime=uspace
$ make
$ sudo make setuid

10 - Copy a set of ini/hal files to ~/linuxcnc/configs/... and modify
them to use the new hm2_rpepp driver

11 - test

Thanks for the step-by-step instructions. In the past I had set up a
c

Re: [Emc-developers] More RPI possibilities

2017-06-20 Thread EBo

On Jun 20 2017 12:20 PM, Gene Heskett wrote:

On Tuesday 20 June 2017 13:03:01 EBo wrote:

On Jun 20 2017 10:47 AM, andy pugh wrote:
> On 20 June 2017 at 17:27, Bertho Stultiens <ber...@vagrearg.org>
>
> wrote:
>> It should work, but it is not "nice". There are several problems,
>> especially wrt. the RPi outputs. How did the design perform in 
the

>> real
>> world?
>
> Hard to tell, this was a few years ago and using a kernel of 
unknown

> quality.
> As in, it didn't work well when I tried it with a software stepgen
> at Wichita, but there were many other possible explanations for 
the

> issues.

Anyone tried it with the new RPi-3's?

I am running it quite well on the the r-pi-3b's, newer single spi
interface on 3/4 ton of old Sheldon lathe.  I say newer because the
hm2_rpspi.so driver I am running has grown some additional legs by
Bertho S. and was just accepted into master.  It (the raspi-3b)  is
kernel picky though, bad keyboard and mouse missfires with the newer
kernels like the 4.9.x. from Frank Durr.

4.4.4-rt9-v7+ is working the best here ATM.  With a Mesa 7i90 in the
bottom of the pile, and 3 7i42TA's on top for surge suppression and
noise filtering to protect the 3.3 volt 7i90, not to mention giving 
us a

decent place to terminate all the wires, I seem to be ready to rock &
roll.  I am collecting tooling, and considering a 4 jaw chuck, and 
I've

already made some of its parts to cnc it, on it.  I have the 3 jaw
within about 1.5 thou of true, lots better than it was when we horsed 
it

out of the cargo van here a year ago.

Thanks Gene for the update.  All good to know.  I will have to review 
the kernel updates, and look into the keyboard and mouse missfires.  All 
that said it would be nice to get back to this...

  EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More RPI possibilities

2017-06-20 Thread EBo


On Jun 20 2017 11:22 AM, Bertho Stultiens wrote:

On 06/20/2017 07:03 PM, EBo wrote:

It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the 
real

world?
Hard to tell, this was a few years ago and using a kernel of 
unknown

quality.
As in, it didn't work well when I tried it with a software stepgen 
at
Wichita, but there were many other possible explanations for the 
issues.


Anyone tried it with the new RPi-3's?


Well, SPI is now working and it seems to be satisfactory. I created 
an
experimental EPP driver for the 7i90/7i43 (which is why I started 
this

thread) but it needs to be tested and I am looking for volunteers.


What all would be evolved with testing?  We found a use at work to use 
an RPi-3 for a proof of concept, so I will be jumping back into RPi's 
for the next while.  It would be nice to make sure that the hard 
real-time and other systems are running correctly, as well as LCNC.  I 
also need to get back to some LCNC projects whenever I can break away 
the time...  Anyway, I or my intern might take a poke at the testing if 
it does not envolve to much, or if we can find a way to make it work 
related...


  EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More RPI possibilities

2017-06-20 Thread EBo


On Jun 20 2017 10:47 AM, andy pugh wrote:
On 20 June 2017 at 17:27, Bertho Stultiens  
wrote:



It should work, but it is not "nice". There are several problems,
especially wrt. the RPi outputs. How did the design perform in the 
real

world?



Hard to tell, this was a few years ago and using a kernel of unknown
quality.
As in, it didn't work well when I tried it with a software stepgen at
Wichita, but there were many other possible explanations for the 
issues.


Anyone tried it with the new RPi-3's?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] QTvcp 4/5 opinions wanted.

2017-04-18 Thread EBo

On Apr 18 2017 2:55 AM, Chris Morley wrote:
> I've been working on a branch that would supply linuxcnc with a
> python QT based vcp program.
>
> This is capable of GLADEvcp type panels and operator screens
> including python handler files.

for clarity, I am assuming that vcp stands for virtual control panel.

> Qt seems to be the future of GUIs
>
>
> The questions I am wonder on are:
>
>
> python 2 or 3 ?

if you are careful you can write it for both.  Use  the v3 print ism's 
and try/except for the package/language dependencies.

> PYQT4 or 5 ?

what is the long term support of v4?  Otherwise if you do not go with 
v5 you are stuck porting in a year or two.

> Currently it's built with python 2 and PYQT4.
>
>
> My personal opinion is that I see little reason to use python 3 yet -
> it seems many libraries are slow to switch.

compatibility note above...

> QT5 is not available in wheezy but is available in Mint (a fairly
> common used distribution)
>
> Looks like debian Jessie has PYQT5 in both styles of python.
>
>
> So to use QT5 we would not be able to use QTvcp in wheezy and  i
> would need some make file help

Do we have any sense for how that would impact development?  Is there 
any planned support for wheezy?

> to juggle when to build and not.
>
>
> I haven't read any significant  differences between qt4/5 I just
> would like to future proof the work.

I would say this is the kicker.  If upgrading from v4 to v5 is 
painless, then there is no worries.  Otherwise you have to make a 
decision.  How hard would it be to implement a migration test?

> it's really disappointing the debacle of GTK2 and 3.
>
>
> Opinions other comments?

Best of luck, and I truly hope you do not find yourself descending to 
the 5'th level of dependency hell.

   EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LED colours in Halshow,

2017-01-27 Thread EBo

On Jan 27 2017 8:46 PM, andy pugh wrote:
> On 28 January 2017 at 03:10, EBo <e...@sandien.com> wrote:
>> I would have to dig around, but I remember that there are 
>> standardized
>> color schemes for such things.  It is also important in that there 
>> are
>> people with something called "color blindness",,,
>
> There is an ISO standard, but that assumes context. Red = bad green =
> good, yellow  = information
>
> There is no way to know the subjective value of a HAL pin, it could 
> be
> "True, the machine is definitely on fire" or "true, all parts made
> today passed inspection"

Fair enough.  Would that mean that the hal pins need another attribute 
"color for value"?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LED colours in Halshow,

2017-01-27 Thread EBo

I would have to dig around, but I remember that there are standardized 
color schemes for such things.  It is also important in that there are 
people with something called "color blindness",,,

On Jan 27 2017 7:52 PM, andy pugh wrote:
> Maybe everyone has been assuming "it must be only me" for the last
> several years.
> iI took a recent forum post[1] for me to realise that, actually, Red
> for False and Yellow for True is _not_ obvious.
>
> On IRC PCW suggested that Black for false and Bright Green for true
> would be unambiguous and not be confused with the current scheme.
>
> [1]
> 
> https://forum.linuxcnc.org/24-hal-components/32241-mpeg-pendant-6-axis-axis-a-b-c-no-move-please-help-cnc-ver-2-3-0
>
> --
> 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
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Torch Height Control

2017-01-24 Thread EBo

On Jan 24 2017 6:29 AM, andy pugh wrote:
> On 24 January 2017 at 00:06, John Thornton <j...@gnipsel.com> wrote:
>> if(enable){
>> float min_velocity = requested_vel
>> -(requested_vel*(1/velocity_tol));
>> if(current_vel > 0 && current_vel >= 
>> min_velocity){vel_status = 1;}
>> else {vel_status = 0;}
>>
>> if(torch_on && arc_ok && vel_status){ // allow correction
>> //if(volts_requested - volts > volts_limit){
>> //volts = volts_requested - volts_limit;
>> //}
>> //else if(volts_requested + volts > volts_limit){
>> //   volts = volts_requested +volts_limit;
>> //}
>> if (abs(volts_requested - volts) > voltage_tol) {
>> offset += (volts_requested - volts) * p_gain;
>> }
>> last_z_in = 0;
>> }
>
>
> The code for an actual PID is pretty simple.
>
> static double olderror, iterm
> if(torch_on && arc_ok && vel_status){ // allow correction
> error = (volts_requested - volts)
> dterm = (error - olderrer) * Dgain
> olderror = error
> iterm += error * Igain
> pterm = error * Pgain
> if (absf(error) > deadband){
>  offset += pterm + iterm + dterm
> }
>
> Is close. You probably need to initialise olderror intelligently, to
> avoid a single-cycle crazy value.

I am not completely convinced that the offset calculation in case of 
"absf(error) > deadband" is sufficient.  The various terms might still 
give you an unreasonable offset.  Might need to clamp that as well, but 
I am not fully sure what that would imply.

   EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving "Simple G-Code Generators" to GitHub?

2017-01-22 Thread EBo

On Jan 22 2017 5:21 AM, Nicholas Humfrey wrote:
> On 2017-01-17 23:05, Nicholas Humfrey wrote:
>> On 2017-01-17 16:50, Sebastian Kuzminsky wrote:
>>> On 01/17/2017 09:41 AM, Jon Elson wrote:
>>>> On 01/17/2017 09:15 AM, Sebastian Kuzminsky wrote:
>>>>>
>>>>> ...
>
>
> It took a lot more work than I was anticipating but I have gathered 
> it
> all together into a Git repository:
>
> https://github.com/njh/simple-gcode-generators
>
> I decided to create a separate directory for each of the scripts, to
> keep the README, script, screenshot and other files together. Where
> there were multiple versions, I have checked in each version, so that
> its history is preserved.
>
>
> Would somebody be able to help with moving it to the 
> github.com/linuxcnc
> organisation?

Thanks for all the hard work Nick!

   EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving "Simple G-Code Generators" to GitHub?

2017-01-17 Thread EBo

On Jan 17 2017 10:36 AM, John Thornton wrote:
> That makes sense to me.
>
> JT
>
>
> On 1/17/2017 11:01 AM, sam sokolik wrote:
>>
>> On 1/17/2017 10:57 AM, EBo wrote:
>> Or make them fit something like native cam or  ngcgui?

That quote was not mine, but I am not objecting to it...

   EBo --

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving "Simple G-Code Generators" to GitHub?

2017-01-17 Thread EBo

On Jan 17 2017 9:50 AM, Sebastian Kuzminsky wrote:
> On 01/17/2017 09:41 AM, Jon Elson wrote:
>> On 01/17/2017 09:15 AM, Sebastian Kuzminsky wrote:
>>> It looks to me like the code on that wiki page is mostly
>>> of the "conversational programming" sort, where a GUI
>>> window asks the user to poke & prod buttons and things to
>>> make some g-code. If so, it might fit in the "wizards.git"
>>> repo we have at git.linuxcnc.org:
>>> http://git.linuxcnc.org/gitweb?p=wizards.git;a=summary
>> I have a bunch of these conversational programs, written in
>> c, for things like :
>> rectangular slot/pocket
>> trepan rectangular slot
>> trepan rectagular slot with ramp Z
>> trepan an oval (racetrack) cutout
>> hole/round pocket
>> trepan hole
>> trepan hole with ramp Z
>> thread mill
>> a circular pattern of holes
>> rectangular array of holes
>> random pattern of holes, taking coordinates from a file
>> cut circular groove, as for an O-ring
>>
>> And, I've converted one of these to Python, but it was slow
>> going, as I'm not really up to speed on Python, yet.
>>
>> Would these be appropriate?
>
> The difficulty with the consolidation/management project that 
> Nicholas
> proposed isn't so much in writing the different conversational 
> wizards,
> it's in getting a consistent look-and-feel and consistent behavior 
> from
> code contributed by different authors, and in adding all the wizards
> that are useful and understandable, while still being choosy enough 
> that
> the good stuff doesn't get buried under an avalanche of personal 
> one-offs.
>
> I think of this as more of a manager/editor type of task rather than 
> a
> hacker/coder type of task.

Another way of handling it would be to give a template for code 
standards, and separate all of the interfaces and set them up as 
plugins.  They you can do a voting thing for the good, the bad, and the 
ugly...

   EBo -

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

2017-01-14 Thread EBo

On Jan 14 2017 8:37 AM, Gene Heskett wrote:
> On Saturday 14 January 2017 08:39:44 EBo wrote:
>
> [...]
>
>> It seams a little heavy handed to repurpose M7-9.  My not just 
>> define
>> your own M101-199?
>
> I probably should have, but this way I have check-button controls for
> both with a mouse click. Lcnc axis needs to grow the ability to put 
> more
> labeled check boxes on the left, control panel, just for such uses.  
> So
> I used what it brung to the pot luck dinner.

Fair enough.

>> That does pose the question that vacuum chip
>> removal that we should probably find and implement a code for it (or 
>> a
>> code that toggles yet another power plug).  I can intuit repurposing 
>> a
>> power switch for the vacuum, but if anyone reads your code they 
>> might
>> not know that you repurposed the coolant to vacuum on that machine.
>
> The actual control is by switching a charge pump, which results in 
> about
> 500 ms lag. Seemed better than having the vacuum come on when lcnc 
> was
> stopped.  The charge pump detector in turn drives a ice cube to 
> switch
> half of a duplex.

The charge pump can be pulled low, and then pumped back up, but yes, 
failure modes and power cycling behaviour is very important.

>> Also, if there is any type of feedback line, you could try putting a
>> pressure regulator in line, or maybe a delay circuit/relay in the
>> path. I once had a machine with something like this
>> <http://timerco.com/index.php?l=product_detail=41> wired in.  What 
>> I
>> am thinking is that a change of state of the air valve triggers a 
>> 1.5
>> second signal trigger.  You may be able to wire it inline with
>> whatever you use to read tool-touchoffs and as soon as the line goes
>> active again, you continue the program.  Just a thought, and without
>> looking at the schematics of your machine I am not sure what could 
>> be
>> wrangled.
>
> The pressure switch, with a huge mechanical hysteresis I can get at 
> TSC,
> and if the tire pump ever gets assembled, would be used as the 
> pressure
> tally.
>
>> Also, isn't there some way to access any GPIO pins external to the
>> main controller?  Somewhere I thought I saw someone hooking up an
>> arduino, triggering a program, and waiting for a response.  Maybe 
>> that
>> was not with LCNC...
>
> Someone probably has. :) But I am nearly out of gpio on that 5i25 as 
> both
> ports are hooked up now, and if I ever put a rotary table on it, I'll
> have to move whats gpio on p3 since there doesn't seem to be a way to
> specify where (p2-p3) another stepgen would appear if enabled. The
> config has an A axis, commented put because I needed the gpio for
> something else, home switches maybe as I had not at that point added 
> a
> bob on p2. I need to change my style, and put gpio useage starting at
> the top of p2. Thats what I am doing with the 7i90 on this lathe. 
> gpio
> stuff, like the controls for the SpinX1 for the vfd, are all on the 
> top
> end of P3, at gpio.071, 070, and 069. So I can add all sorts of stuff
> w/o haveing to rewire stuff later.

Good note on planning forward.

>> Anyway, hope that helps.
>
> It gets the discussion going, and shows a bit of learning on my part 
> too.

That is what I was really hoping.  Basically you pointed out a couple 
of shortcommings on the UI design, and suggestions on layout.  Might 
make the beginnings of a nice section in the docs, on recommended layout 
rational.

   Best of luck!

   EBo --

--
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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Max velocity slider and pure rotary motion

2017-01-14 Thread EBo

Both motion holds would of course be queue breakers, but for 
> long
> moves, like sharpening a tool with a diamond disk, where the moves 
> would
> be say 95 degrees, it would still be faster.
>
> Sure, I can write it in gcode, but making it work completely self
> contained would be handier than that famous sliced bread or bottled
> beer. As is I have to set that angular speed limit to about 5% of 
> what
> it can do if 100 psi of air is being fed into the face groove.
>
> So, I guess I'll keep writing code the old way. But I'd still need 2 
> or 3
> more mist/flood type of control signals out of motion on the G0704 as 
> I
> have already repurposed both mist and flood, the m7-8-9 functions on
> that machine. m7 turns on the vacuum cleaner for chip collection, and 
> m8
> enables a positioning flapper to fall down when a new piece of wood 
> is
> being mounted, and an m9 turns off the vacuum and lifts the flapper 
> out
> of the way so its not destroyed by the machining of the same face the
> flapper sets the position of. The machine is lifted far enough the
> flapper is clear to swing, and it has to run about 13" to start the 
> next
> pass, so I turn the vacuum back on as it lowers the head for the next
> pass. 10 seconds of peace and quiet, :)

It seams a little heavy handed to repurpose M7-9.  My not just define 
your own M101-199?  That does pose the question that vacuum chip removal 
that we should probably find and implement a code for it (or a code that 
toggles yet another power plug).  I can intuit repurposing a power 
switch for the vacuum, but if anyone reads your code they might not know 
that you repurposed the coolant to vacuum on that machine.

Also, if there is any type of feedback line, you could try putting a 
pressure regulator in line, or maybe a delay circuit/relay in the path.  
I once had a machine with something lie this 
<http://timerco.com/index.php?l=product_detail=41> wired in.  What I 
am thinking is that a change of state of the air valve triggers a 1.5 
second signal trigger.  You may be able to wire it inline with whatever 
you use to read tool-touchoffs and as soon as the line goes active 
again, you continue the program.  Just a thought, and without looking at 
the schematics of your machine I am not sure what could be wrangled.

Also, isn't there some way to access any GPIO pins external to the main 
controller?  Somewhere I thought I saw someone hooking up an arduino, 
triggering a program, and waiting for a response.  Maybe that was not 
with LCNC...

Anyway, hope that helps.

   EBo --

--
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-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] tooledit_widget modifications

2016-12-29 Thread EBo

On Dec 29 2016 8:14 AM, Jim Craig wrote:
> replies are Inline below.
>
> On 12/29/2016 8:52 AM, EBo wrote:
>> I will also inline as below...
>>
>> On Dec 29 2016 6:42 AM, Jim Craig wrote:
>>> See my replies below inline.
>>>
>>> On 12/28/2016 7:59 PM, Chris Morley wrote:
>>>> ...
>>>>
>>>> When I entered a value the cursor moves down to the next tool 
>>>> rather
>>>> then the next axis of the same tool.
>>>>
>>>> I would think this is not what you wanted?
>>> This is what I wanted. It is the way most spreadsheets work. If the
>>> group does not like enter moving down then we can remove that
>>> functionality or put it in as optional. Then the programmer using 
>>> the
>>> widget would have to decide to use it or handle the option in their
>>> main application.
>> Would it be reasonable to set up a key/functionality map?  I am not
>> sure it would be worth it, but I can see places where we might want 
>> to
>> map a different key to a function or possibly map a macro.
>
> I am not sure about this. I am sure it is possible but would it be 
> worth it?

Agreed.  There may be some other code around to template this.  
Unfortunately I am away from home on an emergency and do not have ready 
access to my LinuxCNC systems.

>>>> If I hold down cursor up (or down) to get to the first or last 
>>>> tool,
>>>> it pauses at that tool, just as I would expect.
>>>>
>>>> But when I release the button it then moves again which is 
>>>> slightly
>>>> annoying.
>>> Well the function actually handles the key release event due to
>>> issues
>>> with using the key press event occurring before a value is 
>>> accepted.
>>> I
>>> am not sure why it is pausing at the first or last tool. I will 
>>> check
>>> on
>>> that. Good test! I did not do the hold key test in my testing.
>> Is there any way to either set up an automated test suite or 
>> possibly
>> just a list of these tests?  As a note, I *know* that automated GUI
>> testing is difficult (pre-Y2K I worked for a company that did 
>> exactly
>> this).  There are some open source testers that might work
>> <https://en.wikipedia.org/wiki/Comparison_of_GUI_testing_tools>, but 
>> I
>> have absolutely no experiences with any of them.
>
> I will look into this, but as with you I have no experience with 
> these.

Understand.  Since this is mostly a GUI interface, if you can then just 
add a file in with the source some place on a test/expect procedure then 
we can replicate by hand if/when needed.

   EBo --


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] tooledit_widget modifications

2016-12-29 Thread EBo

I will also inline as below...

On Dec 29 2016 6:42 AM, Jim Craig wrote:
>
> See my replies below inline.
>
> On 12/28/2016 7:59 PM, Chris Morley wrote:
>> ...
>>
>> When I entered a value the cursor moves down to the next tool rather 
>> then the next axis of the same tool.
>>
>> I would think this is not what you wanted?
>
> This is what I wanted. It is the way most spreadsheets work. If the
> group does not like enter moving down then we can remove that
> functionality or put it in as optional. Then the programmer using the
> widget would have to decide to use it or handle the option in their 
> main
> application.

Would it be reasonable to set up a key/functionality map?  I am not 
sure it would be worth it, but I can see places where we might want to 
map a different key to a function or possibly map a macro.

>> If I hold down cursor up (or down) to get to the first or last tool, 
>> it pauses at that tool, just as I would expect.
>>
>> But when I release the button it then moves again which is slightly 
>> annoying.
>
> Well the function actually handles the key release event due to 
> issues
> with using the key press event occurring before a value is accepted. 
> I
> am not sure why it is pausing at the first or last tool. I will check 
> on
> that. Good test! I did not do the hold key test in my testing.

Is there any way to either set up an automated test suite or possibly 
just a list of these tests?  As a note, I *know* that automated GUI 
testing is difficult (pre-Y2K I worked for a company that did exactly 
this).  There are some open source testers that might work 
<https://en.wikipedia.org/wiki/Comparison_of_GUI_testing_tools>, but I 
have absolutely no experiences with any of them.

   EBo --

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G71

2016-12-04 Thread EBo

I also have a jig to set the depth of common tools like drills and 
mills, so that I can have 5 duplicates of the same tool and not have to 
worry about the offsets because it is already set.  It does take the 
extra time to set it carefully instead of simply mounting, measuring, 
and setting the offsets.


On Dec 4 2016 9:19 AM, Filipe Tomaz wrote:
> In my lathe(s) I have VDI tooling.
> Each tool settles only on its holder, and each tool is numbered. 
> So I
> will always use the same tool without changing offsets or angles.
> Each time I need a new tool, I buy a new holder (VDI) so that my 
> tool
> library gets larger. This is expensive but is very effective at the 
> long
> run, due to time AND to avoid tool collisions. I even do this for 
> drilling
> where I keep each commun drill in each holder.
> Bottom rule is that a lathe collision is very nasty and make you 
> think:
> "Why didn't I use the manual one ..."
>
> By the way, I sell toolholders :-)

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

Re: [Emc-developers] G71... was Distributing remaps

2016-11-16 Thread EBo

On Nov 16 2016 9:11 AM, Chris Radek wrote:
> On Wed, Nov 16, 2016 at 08:15:42AM -0600, dragon wrote:
>> Below is a link to an email thread where Ben Potter submitted a 
>> patch
>> set to implement g71 into the interpreter in 2012. It was never 
>> accepted.
>>
>> 
>> https://sourceforge.net/p/emc/mailman/emc-users/thread/000601cd831d%24bc81b600%2435852200%24%40org/#msg29723177
>>
>> Andy Pugh has updated the patch set to apply to the 2.8 branch (big
>> thanks Andy!)...
>>
>> https://github.com/LinuxCNC/linuxcnc/tree/BenPotter/G71
>>
>> I would really appreciate some feedback as to what needs done for 
>> this
>> to get accepted. I don't want to spend a bunch of time on it if it 
>> isn't
>> going to go anywhere. It would be great if it can be used as a 
>> starting
>> point to finally get the lathe roughing cycles implemented.
>>
>> Thanks,
>> Todd
>
> Hi Todd, it was good to meet you at fest and I'm glad you're still
> interested in this.  It looks like Ben's work is a terrific starting
> point, and I am super excited and I want to help you however I can.
>
> I did a basic review and added some comments to
>
> 
> https://github.com/LinuxCNC/linuxcnc/commit/0da9a50f30bb575d557b6617fa0fb0b228216f43
>
> Here are my thoughts about what it would take to make this
> mergeable, in approximate order of my own feeling about importance,
> from necessary to wishful:
>
> Verify by eyeball the output for a variety of paths and fixup
> accordingly
>
> Verify that non-type-1 paths always give an appropriate error
> message (and not bogus motion).  I think I found an error check that
> was wrong (I added a comment), so I think this is not well-tested
> yet.
>
> Verify that you can't easily break the algorithm without getting
> suitable error messages, such as by doing things like changing units
> in the middle of the profile definition, switching between radius
> and diameter modes, mixing IK and R arcs, using R arcs with negative
> radius, N words out of order, block delete, requesting multiturn
> arcs, requesting depths that are negative or bigger than the path,
> etc etc. and convince yourself it always either gives a good path or
> gives a coherent error

with all this verification and reproducing errors, please try to write 
a unit test for the testing framework -- so that we can catch it if/when 
it breaks.


   EBo --


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

Re: [Emc-developers] New to developers list --> gschem symbols <-- Back annotation

2016-10-29 Thread EBo

On Oct 29 2016 4:03 AM, andy pugh wrote:
> On 28 October 2016 at 18:36, Nicklas Karlsson
>  wrote:
>> Are there a method to probe the hardware without a *.hal file?
>
> Yes, the software can send individual HAL commands.

Is there already a how-to on doing all this?

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

1 2 3 4 5 6 7 8 9 >

1 - 100 of 832 matches

Mail list logo