[Emc-developers] rt preempt

[Rene Hopf via Emc-developers]

Rt preempt is now mainline.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=baeb9a7d8b60b021d907127509c44507539c15e5
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] lcnc bug in master?

[Rene Hopf via Emc-developers]

On 16.10.23 00:00, gene heskett wrote:

On 10/14/23 10:17, gene heskett wrote:

On 10/14/23 09:13, Sam Sokolik wrote:

I have actually seen this playing with axis from master on bookworm.  At
some point the refresh button in axis just quits working.  You have to
physically re-open the gcode file for the changes to show up.  Then the
refresh button will work for a bit.

I thought it was just me...


https://github.com/LinuxCNC/linuxcnc/issues/2490
could this be related?



Nope, Sam, that green reload button (axis interface) has been funkity 
for quite some time, but seems to have gotten more like tits on a boar 
hog lately. At one point yesterday, I tried it, and got different 
code, that contained 2 lines I had removed from that file back in 
September when I decided to make two different programs out of it 
instead. This was a 30 line file, one operation in a while loop. 
Reloading by filename(menu->open) was the only way I could get the 
results I had just edited into the file, back into lcnc, the 
menu->reload was also getting old code. geany launched from the 
menu->edit.


That really ought to set a flag to do the reload automatically when 
geany exits.


I first thought geany was starting to do gedit's 54 pickup tricks but 
several subsequent cats of the file were correct but lcnc was 
reloading old code.


I just verified this on my sixty40 mill too, I have to use the 
menu->open pulldown to get the code I just edited 30 seconds before.

Cheers, Gene Heskett.


Cheers, Gene Heskett.



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

Re: [Emc-developers] RFC: Reduce number of HAL pin types.

[Rene Hopf via Emc-developers]

On 11.10.23 11:21, Rod Webster wrote:

How would that work when you need to match a pin type with an external data
structure?
eg. An ethercat 16 bit long pin or a  gpio structure
Sometimes pins are manipulated as bit maps.

You really need to consult widely on that

I dont see how that doesnt fit into 64 bit?
its the job of the driver to scale the external data to hal.
lcec has a scale option, that allows you to scale the pdo to whatever 
you want.



Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au


On Wed, 11 Oct 2023 at 19:10, andy pugh  wrote:


General chat at the Stuttgart meetup drifted onto the subject of HAL
pin types, and a suggestion that all pins could be of type "double"
and it would still work. This may actually what the STMBL does.)

A double can exactly represent signed integers up to 43 bits, so this
would actually be an improvement on the HAL version in 2.9

master currently has S64 and U64 types added, and a set of conversion
functions to suit.  This means that there are a total of 7 HAL pin
types (bit, float, S32 U32, S64, U64, port)  and 42(?) conversion
functions.

My proposal, based on further discussion in Stuttgart is to replace
_all_ integer types with Signed-64.  This would very much simplify
many HAL configs which are currently liberally scattered with
conv_NN_NN components. The choice of S32 or U32 in many components
appears to be based purely on the whim of the original coder.

I anticipate this happening in a couple of steps, over a couple of
LInuxCNC major versions.

Step 1 is simply to map all the integer  hal_pin_new*_*()  functions
in HAL to hal_pin_new*_S64() and to replace the integer conv_NN_NN
functions with a simple pass-through.
I think that this would be entirely transparent and would not affect
the function of custom HAL components "out in the wild"

The task of converting the built-in HAL components could then proceed
piecemeal as the opportunity occurred. (for example increasing the
width that is processed in "bitwise")

The other integer types and conversion functions would, at this stage,
just be marked as deprecated.

There is the possibility of making the required HAL changes in the
update_ini script, though it might be non-trivial to get right (And
the changes _should_ be unnecessary)

Apart from a simplification of HAL, this also addresses
https://github.com/LinuxCNC/linuxcnc/issues/2331

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



___
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] RTAI broken again with LinuxCNC

[Rene Hopf via Emc-developers]

On 18.09.23 13:14, andy pugh wrote:

On Sun, 17 Sept 2023 at 02:48, Alec Ari via Emc-developers
 wrote:


hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial declarations are 
only allowed in C99 or C11 mode


Is there a good reason for the RTAI config to force C90 (?) mode? I
looked for where this happens a bit ago and didn't find it.



linux kernel uses gnu11, and so should we.
https://www.kernel.org/doc/html/latest/process/programming-language.html


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

Re: [Emc-developers] C version?

[Rene Hopf via Emc-developers]

> On 9. Jul 2023, at 15:13, andy pugh  wrote:
> 
> On Sun, 9 Jul 2023 at 13:03, Rene Hopf via Emc-developers
>  wrote:
> 
>> looks like there is a flag missing somewhere. our build system is a mess.
> 
> I think it is weirder than that, as I am seeing different behaviour
> with the same source code pulled from git, with the  same OS and gcc
> version.

Look at the compiler command

> 
> -- 
> 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] C version?

[Rene Hopf via Emc-developers]

linuxcnc targets gnu11:

https://github.com/LinuxCNC/linuxcnc/blob/master/src/Makefile#L256

looks like there is a flag missing somewhere. our build system is a mess.

On 09.07.23 02:10, andy pugh wrote:

I recently merged a PR to add a "limit_axis" component. I checked that
it compiles on my test PC (running Buster) but I just now found that
it doesn't compile on the VM that I sometimes use when I need a GUI.

On that machine I see:

hal/components/limit_axis.comp:67:3: error: ‘for’ loop initial
declarations are only allowed in C99 or C11 mode
hal/components/limit_axis.comp:67:3: note: use option -std=c99,
-std=gnu99, -std=c11 or -std=gnu11 to compile your code
make[2]: *** [scripts/Makefile.build:304:
/home/andypugh/linuxcnc-dev/src/objects/hal/components/limit_axis.o]
Error 1
make[1]: Leaving directory '/usr/src/linux-headers-4.19.195-rtai-amd64'

Which version of C does LinuxCNC target?




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

Re: [Emc-developers] Linuxcnc meeting in Stuttgart

[Rene Hopf via Emc-developers]

Meeting will be 6-8 October

On 19.05.23 16:12, Rene Hopf via Emc-developers wrote:
There will be a meeting in stuttgart again. We currently looking for a 
date.


https://nuudel.digitalcourage.de/ZBnmKxmcELW9Nd8C

Rene



___
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] Unable to build LinuxCNC (ld error)

[Rene Hopf via Emc-developers]

I can reproduce the problem, and working on a fix.
https://github.com/LinuxCNC/linuxcnc/issues/2509
as a workaround you can just remove the version script, it isnt actually 
needed.


Rene

On 26.05.23 02:50, Alec Ari via Emc-developers wrote:

Yes but it's been awhile, I've actually done some U-Boot development in the 
past. This problem with the linker is not kernel related though.

Alec






On Friday, May 26, 2023 at 12:00:10 AM UTC, gene heskett  
wrote:





On 5/25/23 19:13, Alec Ari via Emc-developers wrote:

16.0.4

Just throwing this out there; I can write up the docs on how to use it, push 
the image to Github, finalize the installer and then anyone can try getting the 
last bits sorted out hands on. Latency and system performance surpasses Debian 
by a mile, there's also four different PREEMPT_RT kernels to choose from. Some 
kernels may have lower latency than others depending on the platform (i.e. 
Intel vs AMD) which is why I made a few. Adjustments include changes to RCU/CPU 
time keeping and IOMMU support.

Alec



Have you tested any kernels on u-booting arm64's?

Cheers, Gene Heskett.



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

Re: [Emc-developers] Unable to build LinuxCNC (ld error)

[Rene Hopf via Emc-developers]

> On 26. May 2023, at 00:11, Alec Ari via Emc-developers 
>  wrote:
> 
> Right, that's why I'm here. I don't know what's going on and need help. This 
> is the last step then my Gentoo work is done and I can publish everything. 
> LinuxCNC compiled before on Gentoo a few months ago and this is basically the 
> same build, just a newer version of Clang and LLD than before.

Which clang and lld version?


> 
> Alec
> 
> 
> 
> 
> 
> 
> On Thursday, May 25, 2023 at 10:50:44 AM UTC, renehopf--- via Emc-developers 
>  wrote: 
> 
> 
> 
> 
> 
> clang should work fine, there is a github ci job compiling with clang.
> 
>> On 25.05.23 12:04, Alec Ari via Emc-developers 
>>  wrote:
>> Hello,
>> 
>> I think this might be because I'm using Clang+LLD 16 but I'm not sure.. 
>> These look like syntax errors, not an environment/cache issue.
>> 
>> Alec
>> 
>>> ld.lld: error: objects/enum.ver:4: ; expected, but got
>> @;
>> ^
>>> clang-16: error: linker command failed with exit code 1 (use -v to
>>> see invocation)
>>> make: *** [Makefile:1234: ../rtlib/enum.so] Error 1
>>> ld.lld: error: objects/counter.ver:4: ; expected, but got
>> @;
>> ^
>>> ld.lld: error: objects/encoder_ratio.ver:4: ; expected, but got
>> @;
>> ^
>>> ld.lld: error: objects/stepgen.ver:4: ; expected, but got
>> @;
>> ^
>>> clang-16: clang-16: error: error: linker command failed with exit
>>> code 1 (use -v to see invocation)
>>> linker command failed with exit code 1 (use -v to see invocation)
>>> clang-16: error: linker command failed with exit code 1 (use -v to
>>> see invocation)
>>> make: *** [Makefile:1234: ../rtlib/counter.so] Error 1
>>> make: *** [Makefile:1234: ../rtlib/encoder_ratio.so] Error 1
>>> make: *** [Makefile:1234: ../rtlib/stepgen.so] Error 1
>>> ld.lld: error: objects/lcd.ver:4: ; expected, but got
>> @;
>> ^
>>> clang-16: error: linker command failed with exit code 1 (use -v to
>>> see invocation)
>>> make: *** [Makefile:1234: ../rtlib/lcd.so] Error 1
>>> 1 warning generated.
>> 
>> 
>> ___
>> 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
> 
> 
> ___
> 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

[Emc-developers] Linuxcnc meeting in Stuttgart

[Rene Hopf via Emc-developers]

There will be a meeting in stuttgart again. We currently looking for a date.

https://nuudel.digitalcourage.de/ZBnmKxmcELW9Nd8C

Rene



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

Re: [Emc-developers] Next Linuxcnc Online meeting

[Rene Hopf via Emc-developers]

On 06.08.22 17:58, Sebastian Kuzminsky wrote:

On 8/5/22 05:41, Rene Hopf via Emc-developers wrote:

Meeting will be Monday 8.8. 20:00 CEST.


What's the link to join?  I'll try to be there.


https://meet.jit.si/NearbyMythsScoreVery

looking forward to see you all



Thanks for organizing!





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

Re: [Emc-developers] Next Linuxcnc Online meeting

[Rene Hopf via Emc-developers]

Hi,

Meeting will be Monday 8.8. 20:00 CEST.

Looking forward to see you.

Rene

On 04.08.22 11:46, Rene Hopf via Emc-developers wrote:

Hi,

Recently we had an online meeting about things happening in linuxcnc, 
and we chose do do another one.


last time we had a long chat about translations, the build system, and 
toolchangers.


anyone can join, lets find a date and time:

https://nuudel.digitalcourage.de/aNkDAtiHrtsA1RFB

Rene



___
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

[Emc-developers] Next Linuxcnc Online meeting

[Rene Hopf via Emc-developers]

Hi,

Recently we had an online meeting about things happening in linuxcnc, 
and we chose do do another one.


last time we had a long chat about translations, the build system, and 
toolchangers.


anyone can join, lets find a date and time:

https://nuudel.digitalcourage.de/aNkDAtiHrtsA1RFB

Rene



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

Re: [Emc-developers] Quick update on the status of the Debian package

[Rene Hopf via Emc-developers]

the linker errors on arm look like a wrong oder of libs in the build system.

On 07.04.22 16:04, Steffen Möller wrote:

Hello,

I have mentioned this on Rod's github issue on his package woes
(https://github.com/LinuxCNC/linuxcnc/issues/1692) but some more of you
may want to to have a look. The LinuxCNC Debian packaging needed to
adapt to the partial builds (documentation is only built once, not for
all of Debian's platforms) of the Debian autobuilders but now it is
fine. LinuxCNC built for 14 different platforms
(https://buildd.debian.org/status/package.php?p=linuxcnc) and while RISC
V likely has everyone's attention, IBM's big iron s390x seems less
interesting for us.

If nothing happens then the package is expected to migrate to testing
within the next 5 days. The "package tracker" on
https://tracker.debian.org/pkg/linuxcnc gives a good overview. If it is
easy for you then some feedback would be nice. For me, this is just some
technical exercise, still. Please do not use this version in production.

Best,
Steffen



___
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] ImportError undefined symbol PyUnicode_FromString

[Rene Hopf via Emc-developers]

Make sure the user component use python3

https://linuxcnc.org/docs/devel/html/getting-started/updating-linuxcnc.html#_python3_and_gtk3

> On 8. Dec 2021, at 15:29, Curtis Dutton  wrote:
> 

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

Re: [Emc-developers] my pi bytes dust

[Rene Hopf via Emc-developers]

> On 11. Aug 2021, at 10:04, Rob C  wrote:
> 
> Could it be:
> ImportError: No module named hal
> 
> 
> 
> Therefore have you installed python3, given master has now changed to
> Python3, this may (will) also require GTK2 to become GTK3 and some of the
> dependencies will need to be located in the python3 dependencies folder and
> not within the python2 folder (depending upon what gui you are using).

Exactly. Run 2to3 -w on the file, and change the first line to python3, that 
should fix it.

> 
>> On Wed, 11 Aug 2021 at 02:12, Gene Heskett  wrote:
>> 
>>> On Tuesday 10 August 2021 14:44:12 Gene Heskett wrote:
>>> 
>>> Greetings all;
>>> 
>>> After building LinuxCNC from master this morning, my rp4 fails to run
>>> LinuxCNC with this exit stanza:
>>> 
>>> pi@rpi4:/media/pi/workspace $ linuxcnc -l
>>> LINUXCNC - 2.9.0~pre0
>>> Machine configuration directory is
>>> '/home/pi/linuxcnc/configs/sheldon-lathe' Machine configuration file
>>> is '7i90-axis.ini'
>>> Starting LinuxCNC...
>>> Found file(REL): ./hm2-7i90-stepper.hal
>>> Note: Using POSIX realtime
>>> hm2: loading Mesa HostMot2 driver version 0.15
>>> hm2_rpspi: Platform: Raspberry Pi 4 Model B Rev 1.1
>>> hm2_rpspi: Base address 0xfe00 size 0x0180
>>> hm2_rpspi: Mapped peripherals from 0xfe00 (size 0x0180) to
>>> gpio:0x0xb430, spi:0x0xb4304000, aux:0x0xb4315000
>>> hm2_rpspi: SPI0/CE0 clock rate: 41666000/2500 Hz, VPU clock rate:
>>> 5 Hz hm2_rpspi: SPI0/CE0 write clock rate calculated: 4166
>>> Hz (clkdiv=12) hm2_rpspi: SPI0/CE0 read clock rate calculated:
>>> 2500 Hz (clkdiv=20) hm2_rpspi: SPI0/CE0 Valid cookie matched
>>> hm2_rpspi: SPI0/CE0 Base: hm2_7i90.0
>>> hm2/hm2_7i90.0: Low Level init 0.15
>>> hm2/hm2_7i90.0: MD 2: 3x IOPort v0: accepted, using 3
>>> hm2/hm2_7i90.0: MD 0: 1x Hostmot2 DPLL v0: accepted, using 1
>>> hm2/hm2_7i90.0: MD 1: 1x Watchdog v0: accepted, using 1
>>> hm2/hm2_7i90.0: MD 3: 4x Encoder v2: accepted, using 4
>>> hm2/hm2_7i90.0: MD 4: 2x PWMGen v0: accepted, using 1
>>> hm2/hm2_7i90.0: MD 5: 4x StepGen v2: accepted, using 4
>>> hm2/hm2_7i90.0: MD 6: 1x LED v0: accepted, using 1
>>> hm2/hm2_7i90.0: 72 I/O Pins used:
>>> hm2/hm2_7i90.0: IO Pin 000 (P1-01): StepGen #0, pin Step (Output)
>>> hm2/hm2_7i90.0: IO Pin 001 (P1-03): StepGen #0, pin Direction
>>> (Output) hm2/hm2_7i90.0: IO Pin 002 (P1-05): StepGen #1, pin Step
>>> (Output) hm2/hm2_7i90.0: IO Pin 003 (P1-07): StepGen #1, pin
>>> Direction (Output) hm2/hm2_7i90.0: IO Pin 004 (P1-09): Encoder #0,
>>> pin A (Input) hm2/hm2_7i90.0: IO Pin 005 (P1-11): Encoder #2, pin
>>> A (Input) hm2/hm2_7i90.0: IO Pin 006 (P1-13): Encoder #0, pin B
>>> (Input) hm2/hm2_7i90.0: IO Pin 007 (P1-15): Encoder #2, pin B
>>> (Input) hm2/hm2_7i90.0: IO Pin 008 (P1-17): Encoder #0, pin Index
>>> (Input) hm2/hm2_7i90.0: IO Pin 009 (P1-19): Encoder #2, pin Index
>>> (Input) hm2/hm2_7i90.0: IO Pin 010 (P1-21): Encoder #1, pin A
>>> (Input) hm2/hm2_7i90.0: IO Pin 011 (P1-23): Encoder #3, pin A
>>> (Input) hm2/hm2_7i90.0: IO Pin 012 (P1-25): Encoder #1, pin B
>>> (Input) hm2/hm2_7i90.0: IO Pin 013 (P1-27): Encoder #3, pin B
>>> (Input) hm2/hm2_7i90.0: IO Pin 014 (P1-29): Encoder #1, pin Index
>>> (Input) hm2/hm2_7i90.0: IO Pin 015 (P1-31): Encoder #3, pin Index
>>> (Input) hm2/hm2_7i90.0: IO Pin 016 (P1-33): StepGen #2, pin Step
>>> (Output) hm2/hm2_7i90.0: IO Pin 017 (P1-35): StepGen #2, pin
>>> Direction (Output) hm2/hm2_7i90.0: IO Pin 018 (P1-37): StepGen #3,
>>> pin Step (Output) hm2/hm2_7i90.0: IO Pin 019 (P1-39): StepGen #3,
>>> pin Direction (Output) hm2/hm2_7i90.0: IO Pin 020 (P1-41): PWMGen
>>> #0, pin Out0 (PWM or Up) (Output) hm2/hm2_7i90.0: IO Pin 021
>>> (P1-43): PWMGen #0, pin Out1 (Dir or Down) (Output) hm2/hm2_7i90.0:
>>> IO Pin 022 (P1-45): IOPort
>>> hm2/hm2_7i90.0: IO Pin 023 (P1-47): IOPort
>>> hm2/hm2_7i90.0: IO Pin 024 (P2-01): IOPort
>>> hm2/hm2_7i90.0: IO Pin 025 (P2-03): IOPort
>>> hm2/hm2_7i90.0: IO Pin 026 (P2-05): IOPort
>>> hm2/hm2_7i90.0: IO Pin 027 (P2-07): IOPort
>>> hm2/hm2_7i90.0: IO Pin 028 (P2-09): IOPort
>>> hm2/hm2_7i90.0: IO Pin 029 (P2-11): IOPort
>>> hm2/hm2_7i90.0: IO Pin 030 (P2-13): IOPort
>>> hm2/hm2_7i90.0: IO Pin 031 (P2-15): IOPort
>>> hm2/hm2_7i90.0: IO Pin 032 (P2-17): IOPort
>>> hm2/hm2_7i90.0: IO Pin 033 (P2-19): IOPort
>>> hm2/hm2_7i90.0: IO Pin 034 (P2-21): IOPort
>>> hm2/hm2_7i90.0: IO Pin 035 (P2-23): IOPort
>>> hm2/hm2_7i90.0: IO Pin 036 (P2-25): IOPort
>>> hm2/hm2_7i90.0: IO Pin 037 (P2-27): IOPort
>>> hm2/hm2_7i90.0: IO Pin 038 (P2-29): IOPort
>>> hm2/hm2_7i90.0: IO Pin 039 (P2-31): IOPort
>>> hm2/hm2_7i90.0: IO Pin 040 (P2-33): IOPort
>>> hm2/hm2_7i90.0: IO Pin 041 (P2-35): IOPort
>>> hm2/hm2_7i90.0: IO Pin 042 (P2-37): IOPort
>>> hm2/hm2_7i90.0: IO Pin 043 (P2-39): IOPort
>>> hm2/hm2_7i90.0: IO Pin 044 (P2-41): IOPort

Re: [Emc-developers] RIP error with latest Master branch

[Rene Hopf via Emc-developers]

On 02.08.21 08:51, Rod Webster wrote:

Yes python3-gi-cairo is installed (It was missing)
You should not ask about the OS. Running Linux on a Chromebook for testing.
Its been fine up until now.


a user on discord had the issue on bullseye, and it was fixed by 
installing python3-gi-cairo.


if you do not provide information about the os you are using, no one can 
help you.


"fine up to now" doesnt really tell anything, as there have been major 
changes.




Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au



On Mon, 2 Aug 2021 at 07:53, Rene Hopf  wrote:


On 01.08.21 23:08, Rod Webster wrote:

I've been trying to get Linuxcnc running after pulling the very latest
version.
I successfully compiled the code.

I had a lot of Python dependencies to resolve but finally I am getting
errors from Linuxcnc code

I am getting the following error regardless of the GUI sim I run

(including

Axis)
   File "/home/rod/linuxcnc-dev/lib/python/glnav.py", line 19, in
use_pango_font
  pango_context = PangoCairo.create_context(context)
KeyError: 'could not find foreign type Context'

Is there a dependency I have missed?

is python3-gi-cairo installed? which os are you on?

Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au

___
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



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

Re: [Emc-developers] RIP error with latest Master branch

[Rene Hopf via Emc-developers]

On 01.08.21 23:08, Rod Webster wrote:

I've been trying to get Linuxcnc running after pulling the very latest
version.
I successfully compiled the code.

I had a lot of Python dependencies to resolve but finally I am getting
errors from Linuxcnc code

I am getting the following error regardless of the GUI sim I run (including
Axis)
  File "/home/rod/linuxcnc-dev/lib/python/glnav.py", line 19, in
use_pango_font
 pango_context = PangoCairo.create_context(context)
KeyError: 'could not find foreign type Context'

Is there a dependency I have missed?

is python3-gi-cairo installed? which os are you on?


Rod Webster
*1300 896 832*
+61 435 765 611
VMN®
www.vmn.com.au

___
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] GTK3 code in master breaks GTK2 requirements

[Rene Hopf via Emc-developers]

On 01.08.21 03:16, Chris Morley wrote:

Rene, some code you put into master is GTK3 only.
You have broken the code for my systems.
looks like you removed the code that would switch between GTK3 and GTK2
specifically, in hal_glib

I hope this was by mistake.


gtk2 is end of life, and I announced this change to happen on this date 
on the ml about 2 months ago, and I worked on this for over a year. 
there were no objections.


https://sourceforge.net/p/emc/mailman/message/37303177/

all code is gtk3 only now. Which specific part is broken?



Chris

___
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] Sserial bit type parameters

[Rene Hopf via Emc-developers]

On 30.07.21 20:00, andy pugh wrote:

On Fri, 30 Jul 2021 at 18:45, Peter C. Wallace  wrote:


How difficult would it be to add bit type parameters
to the sserial driver? (they are ignored currently)

I imagine that it would be nearly trivial, and if they are currently
ignored then it can only have been an oversight on the part of the
driver author.

I also oppose the change, and agree with andy. can somebody name a 
single benefit?


My school also had a headmaster, and it never occurred to me that I was 
his slave.




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

Re: [Emc-developers] Using `main` instead of `master` branch

[Rene Hopf via Emc-developers]

On 31.07.21 11:35, Alec Ari via Emc-developers wrote:

It's a good thing I don't have commit rights because I'd have a hard time not 
making a `tucker-carlson` branch just for kicks.
I dont think anyone outside the US even knows who that is. Can we please 
keep local political issues past or present off this ML.



___
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] Using `main` instead of `master` branch

[Rene Hopf via Emc-developers]

> On 30. Jul 2021, at 19:01, Michael Freudenreich  wrote:
> 
> I would rather like to see a new feature in software, like the variables 
> which  provide machine coordinates as discussed in the other thread.

That’s already in master.

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

Re: [Emc-developers] Question for the devs

[Rene Hopf via Emc-developers]

On 27.07.21 15:51, Feral Engineer wrote:

Send me what you have, I'll take a look. It should not include tool offsets
of any kind. 5063 (skip position) does, 5043 does (absolute position off of
current work offset) but 5023 should just be the raw machine position from
the home positions (current g53 position).


https://github.com/LinuxCNC/linuxcnc/commit/7c9d834c146488ecef15e2d1f10c0b93107b1dbb

according to what I found they do include the TLO. I did not include it. 
you can always manually add it, or add even more parameters.




Phil T.
The Feral Engineer

Check out my LinuxCNC tutorials, machine builds and other antics at
www.youtube.com/c/theferalengineer

Help support my channel efforts and coffee addiction:
www.patreon.com/theferalengineer

On Tue, Jul 27, 2021, 9:47 AM Rene Hopf via Emc-developers <
emc-developers@lists.sourceforge.net> wrote:


I have added the parameters you asked for. I had the same problem when I
programmed my toolprobe macro. Will push to master shortly. According to
the fanuc docs it includes the tool offset. Does this make sense?


On 27. Jul 2021, at 15:41, Feral Engineer 

wrote:

I think it's brilliant

Goto (standard loop to startpoint with error)
Gotof (forward)
Gotob (backward)
Gotoc (continue looping without error)

It's not so much the fact that they have four goto, it's the fact that

they

have that many ways to do it... If that makes sense. Their manuals
literally have 12 pages of how to program G2/G3 because there are so many
ways to do it. That was kinda my point 😆

Phil T.
The Feral Engineer

Check out my LinuxCNC tutorials, machine builds and other antics at
www.youtube.com/c/theferalengineer

Help support my channel efforts and coffee addiction:
www.patreon.com/theferalengineer


On Tue, Jul 27, 2021, 9:07 AM  wrote:

An interesting set of features! However, "...and four different methods

of

GOTO." doesn't sound like a feature to laud.

-Original Message-
From: Feral Engineer 
Sent: July 27, 2021 8:20 AM
To: EMC developers 
Subject: Re: [Emc-developers] Question for the devs

Simply put, I don't want workarounds, I want a solution as simple as

#5021

to give me the ability to track where my machine is from my home

positions

without having to stand on one foot, rub my belly and hope I'm not using
coordinate rotation. I write logic in Fanuc, Mitsubishi and Siemens
controls constantly and see a lot of missing features in the o code

stuff

that I would be more than happy to address myself if I could ever get to
that level in CPP.

Not sure how familiar you all are with the aforementioned controls, but
I'd be happy to provide manuals for the logic sections of all 3 so you
could see what each one is about. Fanuc and Mits are like 99% identical,
but Siemens is completely different and way more powerful. Some examples
would be that control has both WHILE and FOR loops, 3 dimensional data
arrays, unlimited nonvolatile variable assignment via GUD tables and

four

different methods of GOTO.


Phil T.
The Feral Engineer

Check out my LinuxCNC tutorials, machine builds and other antics at
www.youtube.com/c/theferalengineer

Help support my channel efforts and coffee addiction:
www.patreon.com/theferalengineer


On Tue, Jul 27, 2021, 6:17 AM andy pugh  wrote:


On Mon, 26 Jul 2021 at 19:58, Chris Radek  wrote:
(Note I'm not saying it would be bad to add this feature)

The Fanuc numbers are in unclaimed space in the LinuxCNC parameter
range, so I think I would go further and suggest that it would be good
to add this feature.

I recall this being one of my very first questions on the IRC when I
first started with LinuxCNC. I can't remember why I wanted current abs
position, but I did, and ended up using the G28.1 inelegant
workaround.
(It is inelegant because it has side-effects)

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


___
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


___
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] Question for the devs

[Rene Hopf via Emc-developers]

I have added the parameters you asked for. I had the same problem when I 
programmed my toolprobe macro. Will push to master shortly. According to the 
fanuc docs it includes the tool offset. Does this make sense?

> On 27. Jul 2021, at 15:41, Feral Engineer  wrote:
> 
> I think it's brilliant
> 
> Goto (standard loop to startpoint with error)
> Gotof (forward)
> Gotob (backward)
> Gotoc (continue looping without error)
> 
> It's not so much the fact that they have four goto, it's the fact that they
> have that many ways to do it... If that makes sense. Their manuals
> literally have 12 pages of how to program G2/G3 because there are so many
> ways to do it. That was kinda my point 😆
> 
> Phil T.
> The Feral Engineer
> 
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
> 
> Help support my channel efforts and coffee addiction:
> www.patreon.com/theferalengineer
> 
>> On Tue, Jul 27, 2021, 9:07 AM  wrote:
>> 
>> An interesting set of features! However, "...and four different methods of
>> GOTO." doesn't sound like a feature to laud.
>> 
>> -Original Message-
>> From: Feral Engineer 
>> Sent: July 27, 2021 8:20 AM
>> To: EMC developers 
>> Subject: Re: [Emc-developers] Question for the devs
>> 
>> Simply put, I don't want workarounds, I want a solution as simple as #5021
>> to give me the ability to track where my machine is from my home positions
>> without having to stand on one foot, rub my belly and hope I'm not using
>> coordinate rotation. I write logic in Fanuc, Mitsubishi and Siemens
>> controls constantly and see a lot of missing features in the o code stuff
>> that I would be more than happy to address myself if I could ever get to
>> that level in CPP.
>> 
>> Not sure how familiar you all are with the aforementioned controls, but
>> I'd be happy to provide manuals for the logic sections of all 3 so you
>> could see what each one is about. Fanuc and Mits are like 99% identical,
>> but Siemens is completely different and way more powerful. Some examples
>> would be that control has both WHILE and FOR loops, 3 dimensional data
>> arrays, unlimited nonvolatile variable assignment via GUD tables and four
>> different methods of GOTO.
>> 
>> 
>> Phil T.
>> The Feral Engineer
>> 
>> Check out my LinuxCNC tutorials, machine builds and other antics at
>> www.youtube.com/c/theferalengineer
>> 
>> Help support my channel efforts and coffee addiction:
>> www.patreon.com/theferalengineer
>> 
>>> On Tue, Jul 27, 2021, 6:17 AM andy pugh  wrote:
>>> 
 On Mon, 26 Jul 2021 at 19:58, Chris Radek  wrote:
>>> 
 (Note I'm not saying it would be bad to add this feature)
>>> 
>>> The Fanuc numbers are in unclaimed space in the LinuxCNC parameter
>>> range, so I think I would go further and suggest that it would be good
>>> to add this feature.
>>> 
>>> I recall this being one of my very first questions on the IRC when I
>>> first started with LinuxCNC. I can't remember why I wanted current abs
>>> position, but I did, and ended up using the G28.1 inelegant
>>> workaround.
>>> (It is inelegant because it has side-effects)
>>> 
>>> --
>>> 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
>>> 
>> 
>> ___
>> 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
>> 
> 
> ___
> 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] master-gtk3 and Vismach

[Rene Hopf via Emc-developers]

On 07.07.21 12:41, Rene Hopf via Emc-developers wrote:



On 7. Jul 2021, at 12:24, andy pugh  wrote:

Trying to investigate run-from-line last night (looking at issue
https://github.com/LinuxCNC/linuxcnc/issues/246 ) I found that
sim-axis-vismach-VMC_toolchange doesn't seem to work with master-gtk3.
I don't know if it is specific to that config, or whether there is a
general Vismach problem, or possibly a problem with the current state
of my repository at the time.

I was more interested in other things at the time, so didn't
investigate further, but switching to master made it work again.

Last time I checked vismach worked fine, but I will double check.
there was a problem in the remap, which is now fixed in master-gtk3. 
thanks for reporting it.



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


___
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] master-gtk3 and Vismach

[Rene Hopf via Emc-developers]

> On 7. Jul 2021, at 12:24, andy pugh  wrote:
> 
> Trying to investigate run-from-line last night (looking at issue
> https://github.com/LinuxCNC/linuxcnc/issues/246 ) I found that
> sim-axis-vismach-VMC_toolchange doesn't seem to work with master-gtk3.
> I don't know if it is specific to that config, or whether there is a
> general Vismach problem, or possibly a problem with the current state
> of my repository at the time.
> 
> I was more interested in other things at the time, so didn't
> investigate further, but switching to master made it work again.

Last time I checked vismach worked fine, but I will double check.

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


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

[Emc-developers] gtk3/python3 roadmap

[Rene Hopf via Emc-developers]

Hi,

as already discussed in the PR gtk3 is already very usable, and few bugs 
remain.


If there are no objections or further bugs I will merge this at the end 
of July.


This will default master to python3, and drop support for various legacy 
distributions and python2, so update your machines to Debian 10.


if you use axis, you should not notice a change at all. most glade 
panels work with no or little modifications.


if you need glade, install the version from the linuxcnc repo, or update 
straight to debian 11(ubuntu/mint 20 or later also works). the glade 
version shipped with Debain 10 will not work.


if you have custom python handlers you might need to run 2to3 -w on them.

qtvcp worked the last time I checked, maybe somebody can confirm this.

qtpyvcp is working hard on python3 support, and should be ready soon.

Rene



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

Re: [Emc-developers] curiosity is killing the cat

[Rene Hopf via Emc-developers]

On 04.06.21 21:07, Gene Heskett wrote:

On Friday 04 June 2021 13:31:36 Rene Hopf via Emc-developers wrote:


On 04.06.21 19:20, Gene Heskett wrote:

So the question re master for armhf is in 3 parts:

1: Are you about to switch to building against gtk3?

yes, very soon, but I have not decided on a date. few issues are still
being worked on.


2: How long till python2 support will be turned off?

at the same time.


3: Is there anything I can do with my build scripts or my config to
hasten those dates with my feedback?

check out master-gtk3 branch, and test all your configs.


That machine won't fly unless the buildbot is building it. Its currently
on master-rtpreempt. In which case I need the exact buildbot address,
or, transplant my makeit scripts from the rpi4, which ought to work but
hasn't been tested.  Your choice.

Thanks Rene.


buildbot is building it and packaging works, but I dont think non-master 
branches are uploaded anywhere.


but you can build packages on an other machine.





Cheers, Gene Heskett

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


Cheers, Gene Heskett



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

Re: [Emc-developers] curiosity is killing the cat

[Rene Hopf via Emc-developers]

On 04.06.21 22:12, Dr. Nikolaus Klepp wrote:

Anno domini 2021 Fri, 4 Jun 19:31:36 +0200
  Rene Hopf via Emc-developers scripsit:

On 04.06.21 19:20, Gene Heskett wrote:

So the question re master for armhf is in 3 parts:

1: Are you about to switch to building against gtk3?

yes, very soon, but I have not decided on a date. few issues are still
being worked on.

2: How long till python2 support will be turned off?

at the same time.

3: Is there anything I can do with my build scripts or my config to
hasten those dates with my feedback?

check out master-gtk3 branch, and test all your configs.

nativecam does not work with python3, so all configs with ncam will need some 
work. But that's a different story I think.


It should be easy to port, but afaik currently unmaintained. If somebody 
starts, I'm willing to help.




BTW master-gtk3 builds and runs fine on devuan chimaera, including the HTML 
documentation.

Nik



Cheers, Gene Heskett


___
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] curiosity is killing the cat

[Rene Hopf via Emc-developers]

On 04.06.21 19:20, Gene Heskett wrote:

So the question re master for armhf is in 3 parts:

1: Are you about to switch to building against gtk3?
yes, very soon, but I have not decided on a date. few issues are still 
being worked on.


2: How long till python2 support will be turned off?

at the same time.


3: Is there anything I can do with my build scripts or my config to
hasten those dates with my feedback?

check out master-gtk3 branch, and test all your configs.


Cheers, Gene Heskett



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

Re: [Emc-developers] GTK3

[Rene Hopf via Emc-developers]

On 31.05.21 17:35, andy pugh wrote:

On Mon, 31 May 2021 at 15:34, Rene Hopf via Emc-developers
 wrote:


No newer is available. So now what?

My previous email has a list of alternatives.


I have built several .debs, and uploaded them to linuxcnc. But I am
having problems.

"debuild" only works once. I have not figured out why. I have just
been starting from scratch every time:

dh_install: Cannot find (any matches for)
"usr/share/gtk-doc/html/gladeui-2/*" (tried in ., debian/tmp)
dh_install: libgladeui-doc missing files: usr/share/gtk-doc/html/gladeui-2/*
dh_install: missing files, aborting
make: *** [debian/rules:11: binary] Error 25

If I make a version with the patch then it appears to work as an
installer, but when put on the LinuxCNC repository it looks identical
to the official version, and it isn't clear which one gets installed.

And, so far, if I change the package name, I get an undersized .deb
which appears to install without error, but then I can't see any
executable to run, nor any menu item.

So, there is a package called "glade" on the linuxcnc repository now
which _should_ have been built against Python3, though I am not
completely convinced.


you are missing the libgladeui, which is the actual one which links to 
pyhton.


it decides which one to install based on the version number, the 
cnagnelog file increments the version number.



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



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

Re: [Emc-developers] GTK3

[Rene Hopf via Emc-developers]

> On 31. May 2021, at 15:19, Gene Heskett  wrote:
> 
> On Monday 31 May 2021 07:43:07 Rene Hopf via Emc-developers wrote:
> 
>> all the packages you mentioned are runtime dependencies, please add
>> them.
>> 
>> the problem you see is python2/3 related, but you cant fix it with
>> update-alternatives. I suggest you undo that, as it migh tbreak other
>> packages.
>> 
>> for glade to work you need to run it from commandline with a rip
>> envirionment, which sets the paths.
>> 
>> the problem is the buildin python interpreter in glade, which is set
>> at compile time of glade.
>> 
>> the only solution is to update to a newer glade version.
> 
> But on my buster installs, glade-3.22.1-3 is the newest and installed.  
> No newer is available. So now what?
My previous email has a list of alternatives.
> 
> [...]
> 
> 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 <http://geneslinuxbox.net:6309/gene>
> 
> 
> ___
> 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] GTK3

[Rene Hopf via Emc-developers]

On 31.05.21 14:46, andy pugh wrote:

On Mon, 31 May 2021 at 13:23, Rene Hopf  wrote:

maybe we should ship this deb on the linuxcnc repo.


We already do that for glade-gtk2.

http://www.linuxcnc.org/dists/buster/base/binary-amd64/

I will do the same for glade3-py3


mkdir gladepkg
cd gladepkg
sudo apt-get build-dep glade
apt-get source glade
wget 
https://salsa.debian.org/gnome-team/glade/-/commit/307509c055a6fa21fce1eda03c9dc92eb511381d.diff

cd glade-3.22.1
patch -p1 < ../307509c055a6fa21fce1eda03c9dc92eb511381d.diff
debuild
cd ..



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

Re: [Emc-developers] GTK3

[Rene Hopf via Emc-developers]

On 31.05.21 14:05, andy pugh wrote:

On Mon, 31 May 2021 at 12:43, Rene Hopf  wrote:


all the packages you mentioned are runtime dependencies, please add them.


OK.

the problem you see is python2/3 related, but you cant fix it with

update-alternatives. I suggest you undo that, as it migh tbreak other
packages.


OK.
As it happens, I have found the source of at least some of the problems and
am preparing a commit.

for glade to work you need to run it from commandline with a rip

envirionment, which sets the paths.


That is what I am doing.



the problem is the buildin python interpreter in glade, which is set at
compile time of glade.
the only solution is to update to a newer glade version.


I am running 3.22.1, which appears to be what apt installs on Buster.
Though I see a 3.38.1 on https://glade.gnome.org


looks like debian 10 doesnt have glade with python3.

I see 3 solutions:

- build a glade package with this patch:

https://salsa.debian.org/gnome-team/glade/commit/307509c055a6fa21fce1eda03c9dc92eb511381d

sudo apt-get build-dep glade

apt-get source glade

apply patch

debuild

install deb

maybe we should ship this deb on the linuxcnc repo.

- update to debian 11 bullseye preview

- run ubuntu/mint which comes with glade3 with pyhton3 support




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

Re: [Emc-developers] GTK3

[Rene Hopf via Emc-developers]

all the packages you mentioned are runtime dependencies, please add them.

the problem you see is python2/3 related, but you cant fix it with 
update-alternatives. I suggest you undo that, as it migh tbreak other 
packages.


for glade to work you need to run it from commandline with a rip 
envirionment, which sets the paths.


the problem is the buildin python interpreter in glade, which is set at 
compile time of glade.


the only solution is to update to a newer glade version.

On 31.05.21 13:35, andy pugh wrote:

On Mon, 31 May 2021 at 12:06, andy pugh  wrote:


*ImportError: /home/andypugh/linuxcnc-dev/lib/python/_hal.so: undefined
symbol: _Py_FalseStruct*


Google suggested that this could be due to running Py3 code in Py2, and
when I checked ("python --version") my default Python was still 2.7.

I ran "sudo update-alternatives --install /usr/bin/python python
/usr/bin/python3 10" and now my system defaults to Python 3, but even after
re-building LinuxCNC the Glade editor isn't loading the widgets.

However I am now wondering if the real problem is lower down in the output:

(glade:56119): GLib-CRITICAL **: 12:28:55.441: g_string_insert_c: assertion
'pos <= string->len' failed
(glade:56119): GLib-CRITICAL **: 12:28:55.441: g_string_insert_c: assertion
'pos <= string->len' failed




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

Re: [Emc-developers] GTK3

[Rene Hopf via Emc-developers]

> On 24. May 2021, at 19:05, Nicklas SB Karlsson  wrote:
> 
> Den 2021-05-23 kl. 15:21, skrev Rene Hopf via Emc-developers:
>> Hi,
>> 
>> I cleaned up my gtk3 branch. master-gtk3 on the official repo is now the 
>> place to work on all gtk3 related changes.
>> 
>> https://github.com/LinuxCNC/linuxcnc/pull/1164
>> 
>> anything python3 related shoud go in master, unless it breaks something.
>> 
>> Please test it.
> 
> Think I where able to get the correct version using
> 
> git fetch origin pull/1164/head
> 
> git checkout origin pull/1164/head
> 
> 
> It compile and run but are uncertain about widgets. Then using gtk2 and old 
> version of glade I first run . rip-environment-script then it find the hal 
> widgets. There are no widgets yet?

You can’t use gtk2 or the old glade, It only works with python3 and gtk3. All 
the gladevcp widgets have been ported and are working.

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

[Emc-developers] GTK3

[Rene Hopf via Emc-developers]

Hi,

I cleaned up my gtk3 branch. master-gtk3 on the official repo is now the 
place to work on all gtk3 related changes.


https://github.com/LinuxCNC/linuxcnc/pull/1164

anything python3 related shoud go in master, unless it breaks something.

Please test it.

Rene



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

Re: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in Master.

[Rene Hopf via Emc-developers]

On 12.05.21 11:59, andy pugh wrote:

On Wed, 12 May 2021 at 06:48, Chris Morley 
wrote:

Keeping in mind if a user is using master in older distributions, it may

require the user to upgrade to a new distribution to have python3 support.


Python3 is available on all supported OS versions.


not all python3 versions/dependencies work. currently I cannot tell what 
the oldest version is that can work.


testing welcome. https://github.com/LinuxCNC/linuxcnc/issues/820



Furthermore, Master debs are not built for anything older than Ubuntu 18 or
Debian 10.
https://github.com/LinuxCNC/linuxcnc/commit/cf8ebfe3a5f232b499a85d3fee67c9ee29f4abbd

See, for example:
http://buildbot.linuxcnc.org/buildbot/builders/1630.rip-stretch-rtpreempt-amd64/builds/2795




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

Re: [Emc-developers] Fwd: Re: Proposal: Stop supporting Py2 and GTK2 in Master.

[Rene Hopf via Emc-developers]

On 12.05.21 11:51, andy pugh wrote:

On Wed, 12 May 2021 at 08:00, Chris Morley 
wrote:


I meant a 2.9 python 2 release before switching master to python3


I can see the argument, but I don't think that 2.9 is ready to be a proper
release. And we don't have a 2.9 release manager.

We could consider archiving a set of buildbot .debs as a rollback option
for anyone caught out by the switch, but  master isn't called "2.9" for a
reason, it is not intended for use on any machine where continued operation
is critical.


is there anything currently in master that isnt in 2.8 that people who 
dont want to update their os might need?







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

Re: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in Master

[Rene Hopf via Emc-developers]

On 11.05.21 15:32, Alan Condit wrote:

Andy,

Has anyone familiar with Python looked at migrating to Py3 and GTK3?
I have avoided Python like the plague, but I do use a VCP and/or GTK based 
panels.
I just looked at GTK3 and GTK4 is current, however, they say don’t migrate
  from GTK2 to GTK4 but rather from GTK2 to GTK3.


yes, that is what this is all about, and I have been working on for a 
long time.


https://github.com/LinuxCNC/linuxcnc/pull/943



Alan


Date: Tue, 11 May 2021 13:13:06 +0100
From: andy pugh 
To: EMC developers 
Subject: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in
Master.
This has been discussed a little in an out of the way corner of github:
https://github.com/LinuxCNC/linuxcnc/pull/943#issuecomment-835870729

But I think that the time has come to decide that Py2 support does not
belong in 2.9.
I think that this also means losing GTK2 support(?), so there will be some
breakage of UI and existing VCP panels.

There has been a suggestion to make a final Py2 release based on master,
but I don't know if that would help all that much with those users running
master from Buildbot, as they will probably still end up installing a
Py2-free Master before they notice.

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



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

Re: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in Master.

[Rene Hopf via Emc-developers]

On 11.05.21 15:04, Gene Heskett wrote:

On Tuesday 11 May 2021 08:57:03 Rene Hopf via Emc-developers wrote:


On 11.05.21 14:29, Dr. Nikolaus Klepp wrote:

Does removing GTK2 still break axis? This is the only point why I
have not managed to migrate to chimaera.

Nik

no, axis is tk, and not affected at all.


Actually, its pyvcp that I expect will mortally bleed. But there should
be workarounds as they occur. I use that, a lot in my axis addons.


gladevcp works with gtk3, but embedding them in axis does not: 
https://github.com/LinuxCNC/linuxcnc/issues/863


anyone want to figure out why?



Stay well all.

Cheers, Gene Heskett



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

Re: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in Master.

[Rene Hopf via Emc-developers]

On 11.05.21 14:29, Dr. Nikolaus Klepp wrote:


Does removing GTK2 still break axis? This is the only point why I have not 
managed to migrate to chimaera.

Nik


no, axis is tk, and not affected at all.








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

Re: [Emc-developers] Docs query

[Rene Hopf via Emc-developers]

> On 20. Aug 2020, at 13:34, andy pugh  wrote:
> 
> On Thu, 20 Aug 2020 at 12:21, John  wrote:
> 
>> /usr/bin/env: ‘linuxcnc-python’: No such file or directory
>> make: *** [../docs/src/Submakefile:562: .html-images-stamp] Error 127
> 
> One for Rene,
> https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/linuxcnc-python.in
> 
> If you run ./configure then it looks like a script (linuxcnc-python)
> should be put in /usr/bin/env that calls the installed version of
> Python.
> 
> Though I am a little surprised to see it done as a script rather than a link.

Its not the installed version, that would be easy.
Its the version that was passed to configure script with —with-python.
The script is not available in an installed version, only rip.

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



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

[Emc-developers] Python3

[Rene Hopf via Emc-developers]

Master now builds with python3.
To test on buster:
./configure --with-python=python3 --with-boost-python=boost_python3-py37
I opened a few python3 related issues:
https://github.com/LinuxCNC/linuxcnc/issues?q=is%3Aissue+is%3Aopen+label%3Apython3



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

Re: [Emc-developers] changes in tooltable?

[Rene Hopf via Emc-developers]

> On 13. Apr 2020, at 21:21, andy pugh  wrote:
> 
>> due to a missing libmodbus-dev which apt-get cannot find at this late
>> date for wheezy.
Why not just update to a debian version that still has support?



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

Re: [Emc-developers] Toolchange and tlo behaviour

[Rene Hopf via Emc-developers]

> On 8. Apr 2020, at 12:20, andy pugh  wrote:
> 
> On Wed, 8 Apr 2020 at 03:04, Reinhard  wrote:
> 
>> So the solution to your problems is a tool-manager, that knows all tools and
>> which generates a tooltable for each job, which then gets transmitted to the
>> cnc-controller.
> 
> Many years ago, and working with Tormach, we came up with a powerful
> database schema for a LinuxCNC tool catalogue.
> Amongst other things it supported a shared tool table for all machines
> in the factory (or, indeed, the World) with pre-configured carousel
> layouts and all sorts of other things. (and, being a database, users
> can add fields without breaking the built-in queries)
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolDatabase
> 
> To make use of a database, though, the tool data has to be removed
> from motion / NML. All that needs (as far as I can tell, please tell
> me if I am wrong) is the data for the current tool.
> 
> One of the larger tasks to make that database a reality is to hide it
> from the user, so nothing seems to have changed :-)
> At the time I created my tool database branch (which, incidentally, I
> have now totally re-thought) I had no Python experience, so was not in
> a position to teach tooledit how to handle the new backend complexity.
> 
> Note that the andypugh/tooltable branch has seen no activity since 2013

I picked this up, and will eventually have it working, but one step at a time.
I already had a version that uses sqlite as tooltable, but it requires a lot 
more work.
Tormach rolled their own thing with redis.

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



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

Re: [Emc-developers] Toolchange and tlo behaviour

[Rene Hopf via Emc-developers]

> On 7. Apr 2020, at 21:15, Jeff Johnson  wrote:
> 
> I believe it’s a just lathe thing
> Lathe-fanucy.tbl

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

Re: [Emc-developers] Toolchange and tlo behaviour

[Rene Hopf via Emc-developers]

> On 7. Apr 2020, at 20:47, Jeff Johnson  wrote:
> 
> How does it affect the Fanuc style tool change? T0101 or T0406?

Is this documented anywhere? I can test it.

> 
> Just asking as I may have to update some day. 
> 
> Jeff Johnson
> john...@superiorroll.com
> Superior Roll & Turning
> 734-279-1831
> 
> -Original Message-
> From: andy pugh [mailto:bodge...@gmail.com] 
> Sent: Tuesday, April 07, 2020 2:41 PM
> To: EMC developers 
> Subject: Re: [Emc-developers] Toolchange and tlo behaviour
> 
> On Tue, 7 Apr 2020 at 19:30, Gene Heskett  wrote:
> 
>>> That's currently 1000 tools. Unlikely to be a problem for many.
>> 
>> When did that happen?
> 
> 4 hours ago.
> 
> Do keep up :-)
> 
> https://github.com/LinuxCNC/linuxcnc/commit/b51ef8cc3c560b6c44d095814988a3f972bc0763
> 
> 
> --
> 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
> 
> 
> 
> ___
> 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] Toolchange and tlo behaviour change in 2.8

[Rene Hopf via Emc-developers]

> On 7. Apr 2020, at 19:03, mydani  wrote:
> 
> Did u run all the tests successfully in your rebase? I put some changes on
> top of your work, to totally distinguish between tool table index and
> pocket.

Where can I find them?
Did you have any problems with the branch?
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Toolchange and tlo behaviour

[Rene Hopf via Emc-developers]

> On 7. Apr 2020, at 20:47, Ken Strauss  wrote:
> 
>> -Original Message-
>> From: andy pugh [mailto:bodge...@gmail.com]
>> Sent: Tuesday, April 07, 2020 2:41 PM
>> To: EMC developers
>> Subject: Re: [Emc-developers] Toolchange and tlo behaviour
>> 
>> On Tue, 7 Apr 2020 at 19:30, Gene Heskett  wrote:
>> 
 That's currently 1000 tools. Unlikely to be a problem for many.
>>> 
>>> When did that happen?
>> 
>> 4 hours ago.
>> 
>> Do keep up :-)
>> 
>> https://github.com/LinuxCNC/linuxcnc/commit/b51ef8cc3c560b6c44d095814
>> 988a3f972bc0763
>> 
>> 
>> --
>> atp
>> 
> I have been using Tormach's expanded tool table with 1000 entries and tool 
> descriptions for at least a year. Mine is sparsely populated with premeasured 
> tools but I've implemented a little organization using ranges. For example, 
> tools #101-#160 are drills sized #1 to #60.

Im using the same values Tormach uses, so they should work fine.

> 
> 
> 
> 
> ___
> 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] Toolchange and tlo behaviour

[Rene Hopf via Emc-developers]

> On 7. Apr 2020, at 18:15, Gene Heskett  wrote:
> 
> On Tuesday 07 April 2020 11:34:22 Reinhard wrote:
> 
>> Hi,
>> 
>> On Dienstag, 7. April 2020, 16:13:07 CEST Rene Hopf via Emc-developers 
> wrote:
>>> 1. Fix pocket numbers
>> 
>> I'm no developer, but please allow me to bubble a few thoughts about
>> tooltable, atc, pockets, slots, ...
>> 
>> I'm quite unlucky to work on a machine, where I have to struggle with
>> atc- slots. But I'm convinced absolutely, that's because of the
>> deficits of the tooltable (my machine has nothing that can be called
>> tooltable seriously :(  - tool properties are just entries in
>> onedimensional parameter list) My colleague at work that work on a
>> recent mazak don't have that problem, as mazak machines have a
>> marvelous tooltable. With big comment field, where you can enter
>> meaningful descriptions and a picture, that shows the tool ... cnc-UI
>> shows the tool picture of the current active tool - so cute ;)
>> 
>> My colleagues don't bother with slots. Everything works by toolnumber,
>> even the backdoor of the atc (with about 150 slots), where you can
>> load or unload tools from atc, works with tool numbers and
>> tool-description. Yes, you can search commentfield for substrings :)
>> 
>> So I believe, that an atc should be like a blackbox for linuxcnc (on
>> many machines the atc comes from a different vendor, than the machine)
>> and tit for that - the atc should not be allowed to touch tooltable
>> from linuxcnc. The atc-interface is pretty clear and simple: machine
>> and/or operator ask for toolnumber and the atc should manage its
>> own/private reference-table, where the toolnumber is associated to a
>> slot.
>> The atc does not need to know more about a tool, than its number.
>> But for internal purpose, it will probably need more properties about
>> the slots than just a number. But linuxcnc should not care about
>> internal properties of the atc.
>> There are many flavours of atc, but if the atc is an exchangeable
>> module, only the toolnumber interface is of interest.
>> 
>> So the tooltable in linuxcnc should be extended/changed. Slot field
>> should be removed. Current file format already supports a comment
>> field, axis and some other guis (like mine) read the file that way,
>> but backend of linuxcnc does not support comment in status, which is
>> pretty poor.
>> 
>> I believe, that its a big overshoot to put the tooltable in the
>> nml-status- area. Tooltable-properties are quite seldom requested by
>> ui, so it would be sufficient, if the table or parts of it would be
>> served at request only.
>> 
>> Such a tooltable as described would improve decoupling of modules and
>> would be good deed for users too :)
>> 
>> 
>> cheers Reinhard
>> 
> I'm with Reinhard but it sounds like a major rewrite perhaps belonging in 
> 3.0?.

I have more plans, but they will not be ready for 2.8.
My commit already does part of that, cleaning up the internal handling of 
numbers.

> 
> In any event I'm opposed t0 the automatic reload of the last tool. I home  
> to a safe position, and I sure don't want the last tool used loaded 
> leading to a crash and broken tool when I fire up linuxcnc the next day.

But that is what your machine hardware does. When you restart, it will still 
have the last tool in the spindle.
And that is how it was handled for random changers.
What I don’t understand is, why nonrandom changers should behave different on 
startup.

Not having a tool, but the machine thinking it has a tool is a safe condition, 
as it will store no tool to its pocket.
The current implementation is dangerous, when the machine thinks it has no 
tool, and picks one up without storing the old one.

> 
> 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 <http://geneslinuxbox.net:6309/gene 
> <http://geneslinuxbox.net:6309/gene>>
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net 
> <mailto:Emc-developers@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/emc-developers 
> <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

[Emc-developers] Toolchange and tlo behaviour change in 2.8

[Rene Hopf via Emc-developers]

Hi,
There are a few things I would like to change in 2.8.

1.
Fix pocket numbers
I rebased my pocket number fix to 2.8, and it seems to work ok.
https://github.com/LinuxCNC/linuxcnc/tree/2.8-pocket-fix 

The branch based on 2.6 has been tested and is used by many people.
If you don’t use a tool changer or the tool table, this does not affect you.

2.
Reload tool on startup.
Currently only random tool changers reload the old tool on startup.
I think this is a bug, and dangerous.
It was requested by so many people to change it, that Norbert even implemented 
it in gmoccapy, imho it does not belong in the gui.
If you don’t use a tool changer or the tool table, this does not affect you.

3.
Retain G43
Almost anybody that has ever used any other controller, has crashed a tool with 
linuxcnc due to this behaviour.
Many people complain about it, and there is even a note in the code that 
considers it a bug.
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_convert.cc#L3124-L3134
 

2.8 requires config changes anyway, so its a good time to change it.
If you don’t use a tool changer or the tool table, this does not affect you.

If there are no objections, I will implement all those things.
Where do I need to document the changes, so they show up in the release notes?

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

Re: [Emc-developers] New 2.8 Release Manager

[Rene Hopf via Emc-developers]

> On 3. Apr 2020, at 19:48, andy pugh  wrote:
> 
> The oldest I
> have is probably a D525 from 10 years ago.

D525 has a 64 bit cpu.


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

Re: [Emc-developers] New 2.8 Release Manager

[Rene Hopf via Emc-developers]

> On 3. Apr 2020, at 19:46, andy pugh  wrote:
> 
> On Fri, 3 Apr 2020 at 18:19, Jon Elson  wrote:
> 
>> Another topic is what to do about 32-bit and 64-bit
>> kernels.  I've been too busy to do much, but I
>> suspect there is code in my ppmc driver that will not work
>> right on a 64-bit build.
> 
> There was a discussion about this on the 4th of February and I believe
> that a solution was found.
> However looking on Github i do not see any evidence that the fix was applied.
> 
> As far as the ISO images go RTAI will necessarily be 64-bit. I was
> expecting the same to be true for PREEMPT-RT.
> I would be surprised if many owners of obligate-32 bit systems would
> be intending to upgrade to the latest OS via an ISO install.
> I don't think that I have a 32-bit machine to test on. The oldest I
> have is probably a D525 from 10 years ago.
> 
> Are you in a position to test the drivers on a 64-bit machine?

Thanks Andy for taking care of the release!
I do not see any reason to support 32 bit, any x86 cpu designed in the last 12 
years supports 64 bit.

I also would like to include my pocket fix in 2.8, and am willing to support it.
https://github.com/LinuxCNC/linuxcnc/pull/528 

It only needs another minor fix(and documentation update), and if there are no 
objections I will rebase and merge it.
It does not interfer with any existing tool changer configuration.

I also vote for having the reverse run included.

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


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

Re: [Emc-developers] pktuart -> rs-485

[Rene Hopf via Emc-developers]

> On 25. Mar 2020, at 22:10, Peter C. Wallace  wrote:
> 
> On Wed, 25 Mar 2020, Curtis Dutton wrote:
> 
>> Date: Wed, 25 Mar 2020 14:02:39 -0400
>> From: Curtis Dutton 
>> Reply-To: EMC developers 
>> To: EMC developers 
>> Subject: Re: [Emc-developers] pktuart -> rs-485
>> Apologies. It is a 7i74 not a 7i84.
> 
> BTW a simple way to bisect the testing process is to simply loop back the 
> FPGA TX line to the FPGA RX line, to eliminate any issues with TXEN, 
> polarities, RS-485 driver hookup etc etc

I explained it already, yaskawa is not a uart, its hdlc over Manchester over 
rs485.
It cannot work with the pkguart or ssi driver.
To get it to work with a mesa card requires a new vhdl module. It requires 
clock recovery, so you can’t even just pick bits at times.
This is my implementation in the Stmbl: 
https://github.com/rene-dev/stmbl/blob/master/src/comps/yaskawa.c#L85 

Its decoded with clock recovery by using a timer chained to a dma channel, 
which ends up with a run length encoding in memory.
The request is also generated with the dma.
I can make a pcb that converts all the fb systems the Stmbl supports to sserial.
 
> 
> 
> Peter Wallace
> Mesa Electronics
> 
> 
> ___
> 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.7.15 PID Fix

[Rene Hopf via Emc-developers]

> On 3. Mar 2020, at 17:49, Jon Elson  wrote:
> 
> On 03/03/2020 10:13 AM, andy pugh wrote:
>> We are seeing a number of issues reported to the forum where the fix
>> to the PID command-deriv input is causing problems with existing
>> configurations that net that pin to a signal that is not otherwise
>> connected to a source.
>> 
>> Should we consider a 2.7.16 that reverts this fix, and push the actual
>> fix to 2.8? (where the config updater script would, maybe, be able to
>> do something clever with it.)
>> 
> I've had some reports of odd behavior of PID in very late builds, but didn't 
> have enough info
> to track it down.
> 
> Does anybody have a more specific case of how it is failing?
> 
> (Hmm, why would somebody create a net for the command-deriv with no source?  
> Seems kind of
> odd.)

Pncconf and some default configs do that.

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

[Emc-developers] Linuxcnc meeting 2019 in Stuttgart, Germany

[Rene Hopf via Emc-developers]

Hi,

We are looking for a date for the next linuxcnc meeting in Stuttgart, Germany.
All info here:
https://doodle.com/poll/7aeg98zwbi6qrtvx

Rene



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

[Emc-developers] rt preempt

[Rene Hopf via Emc-developers]

looks like rt preempt is on its way into mainline: 
https://www.youtube.com/watch?v=BxJm-Ujipcg




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

Re: [Emc-developers] New Stuff

[Rene Hopf via Emc-developers]

> On 19. Sep 2018, at 16:27, Moses McKnight  wrote:
> 
> Run-from-line for instance has more problems than that mentioned in #246, it 
> also does very bad stuff if there is a probe move in an external subroutine 
> prior to the line you try to run from.  I implemented what I called "simple 
> run from line" which gives an option to simply run from the given line 
> ignoring everything that came before.  This works well if you are careful 
> where you run from, and works around various bugs.  My "fix" was done on 2.7, 
> but I intended to push it to master and have not gotten back to that.

Im not even talking about complicated stuff, I think run from line is 
completely broken and does not work at all if you use remapped m6.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] New Stuff

[Rene Hopf via Emc-developers]

I agree that 2.8-pre is very stable at the moment, and works great with stretch.
But as far as Im aware those features have already been tested by other people.
A release is probably a very good idea, there are a few things I would like to 
address before:
- https://github.com/LinuxCNC/linuxcnc/issues/246 

- https://github.com/LinuxCNC/linuxcnc/issues/470 

on trivkins machines there should be no axis setting. having 2 sets of vel/acc 
can be confusing(to new users), and lead to very strange behaviour if they 
don't line up.
on stepgens, you also have to adjust the stepgen limits, so you end up with 3 
values...
- increase of tooltable limit(until my fix is finished), to something like 1000
https://github.com/LinuxCNC/linuxcnc/issues/374 

https://github.com/LinuxCNC/linuxcnc/issues/314 

merge of spindle stuff like
https://github.com/LinuxCNC/linuxcnc/pull/354 

and robs various fixes for spindle sync moves.

should I start adding stuff like that to the 2.8 milestone on github? do we 
care about milestones?

Rene


> On 19. Sep 2018, at 06:45, Kurt Jacobson  wrote:
> 
> I agree with Chris. I don't think there could be a better time to release 
> master, 2.8, or whatever it will be called. At this point it has been stable 
> for some time and has been VERY heavily tested and a LOT of people are using 
> it in production. If anything it is more reliable than the current stable. I 
> am a strong proponent of merging Multi Spindle, External Offsets, Revers Run 
> and QtVCP, but I think we should seriously think about releasing master 
> beforehand. If we don't it will probably end up being another year at least 
> before it is released. That would not be bad, but I do think a lot of people 
> would benefit from on official release the supports J/A. (trentster on IRC 
> this evening being a good case in point)
> 
> I also think that jepler's Stretch ISO is ready for prime time and should be 
> put in the spot light as it deserves :)
> Cheers,
> Kurt
> On Sep 19 2018, at 12:14 am, Chris Morley  wrote:
>> 
>> I too agree with merging branch such as you named.
>> I also am interested in merging qtvcp soon.
>> 
>> My question is about merge strategy.
>> Merging invariably will cause/show a couple bugs... that's really the point 
>> of master before release.
>> It's been a long time since a release from master.
>> We could release master before merging a bunch of stuff in - as it seems 
>> pretty stable right now.
>> Or we probably should wait six months after merging major code projects, to 
>> clean up any bugs.
>> 
>> my 2 cents.
>> Chris M
>> 
>> From: andy pugh 
>> Sent: September 18, 2018 12:05 PM
>> To: EMC developers
>> Subject: [Emc-developers] New Stuff
>> 
>> If I am going to merge Multispindle, perhaps we should also look at
>> adding two other things.
>> 
>> 1) External Offsets
>> 2) Reverse Run.
>> 
>> As far as I know neither of these have any effect unless actively enabled.
>> So I see no reason _not_ to merge them.
>> I find myself advocating both branches on the forum reasonably regularly.
>> External Offsets is potentially extremely useful for Plasma THC (and
>> also potentially for PCB engraving, following an STL surface like
>> probekins tried to.)
>> Lots of users are using Plasma with THC, with varying degrees of success.
>> 
>> Reverse run looks useful for wire spark erosion. At least one user is
>> building one of those.
>> 
>> --
>> 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
>> 
>> 
>> ___
>> 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
>> 
> 
> 
> ___
> 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] New Stuff

[Rene Hopf via Emc-developers]

Yes, good idea. This is a good way of checking if there are any issues with 
existing behaviour.
reverse run is also useful to get drills and stuff out of holes on multi axis 
machines.
who is maintaining those branches? will you merge them?

Rene

> On 18. Sep 2018, at 14:05, andy pugh  wrote:
> 
> If I am going to merge Multispindle, perhaps we should also look at
> adding two other things.
> 
> 1) External Offsets
> 2) Reverse Run.
> 
> As far as I know neither of these have any effect unless actively enabled.
> 
> So I see no reason _not_ to merge them.
> 
> I find myself advocating both branches on the forum reasonably regularly.
> 
> External Offsets is potentially extremely useful for Plasma THC (and
> also potentially for PCB engraving, following an STL surface like
> probekins tried to.)
> Lots of users are using Plasma with THC, with varying degrees of success.
> 
> Reverse run looks useful for wire spark erosion. At least one user is
> building one of those.
> 
> -- 
> 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
> 
> 
> ___
> 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] Pull requests

[Rene Hopf via Emc-developers]

> On 20. Jul 2018, at 18:20, Sebastian Kuzminsky  
> wrote:
> 
> 1.  Anyone can *review* PRs, test them, and give their feedback.  This
> is a valuable service to the community.  No special authority is needed,
> just a regular github account.

and thats where a problem is IMHO.
generally there are 2 things to test:
1. if it works as expected
2. if it does not break anything else.

of the few people that run master on their machines, probably even fewer use a 
patched version.
and those who do, only test what they expect and need.

for example, the reverse run is only tested by pepole that need reverse run. so 
how do we ever find out if it breaks anything that does not use reverse run?

Rene
--
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] Buildbot Platforms

[Rene Hopf]

> On 24. May 2018, at 18:55, Sebastian Kuzminsky  wrote:
> 
> Adding support for newer distros and producing installers ISOs with
> realtime kernels for those distros is a significant effort.  Jeff has
> done a fantastic job making sure we run well on RT-Preempt, and
> producing installer ISOs based on Stretch and RT-Preempt.  These are not
> officially released and not widely publicized yet, but I believe they're
> ready for wider distribution.

It would be gerat if they could bundle 4.16 kernel.
4.16 rt preempt is much much better, even on legacy hardware, like core2duo.
PCW also confirms this.

while 4.16 is a great improvement, its too complicated for most users to 
manually patch and compile it.
--
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] strange problem in the hal_ppmc.c driver

[Rene Hopf]

> On 10. May 2018, at 13:43, andy pugh  wrote:
> 
> On 10 May 2018 at 04:55, Jon Elson  wrote:
> 
>> I can't match this commit with
>> 
>> your 1b7feb83
>> 
>> That commit shows up as de7bbf4 in github.
> 
> 1b7feb83
> is
> https://github.com/LinuxCNC/linuxcnc/commit/1b7feb839c15952d6ff867bcfc4cdea7f873976e
> 
> (You can search on github with the hash, but need to click on the
> "commits" label on the screen that says "no code results”)

or use the compare feature: 
https://github.com/LinuxCNC/linuxcnc/compare/v2.7.8...v2.7.9

> 
> -- 
> 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] coding style

[Rene Hopf]

> On 5. May 2018, at 18:03, Sebastian Kuzminsky  wrote:
> 
> * It makes it harder to understand how the meaningful (ie,
> non-whitespace) contents of the file have changed over time.

Thats why the formatting should be done in a format-only commit.

> 
> * It makes it harder to apply patches across the indentation-change
> boundary.  For example, if we reindented master, it would be harder to
> merge bugfixes from 2.7 into master.

not if both are reformatted. formatting does not affect any users, so 2.7 can 
be reformatted no problem.
maybe its a good idea to do it after the 2.8 release?

I know what you are saying, with all those little patches in various branches.
but they can be formatted with the same rules, and then the diff should make 
sense again, I guess?

Rene
--
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] coding style

[Rene Hopf]

> On 5. May 2018, at 12:31, andy pugh  wrote:
> 
> On 5 May 2018 at 11:03, Nicklas SB Karlsson
>  wrote:
> 
>> Some editors like emacs or builtin Eclise may fix this automatically, select 
>> and press a button or two or menu item. Maybe there also is some kind of 
>> command line driven tool so several files could be scanned at once.

but pepole use different editors, thats why ist best to have some independent 
tool.

> 
> The coding style guide specifically warns against "fixing" existing
> code which is otherwise unchanged by a commit as it makes it very
> difficult to see what a commit really does.

agree.
thats why the formatting should be done in a commit that only fixes formatting.

> 
> -- 
> 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] coding style

[Rene Hopf]

> On 4. May 2018, at 14:04, Rene Hopf  wrote:
> 
>> 
>> On 4. May 2018, at 13:55, andy pugh  wrote:
>> 
>> On 4 May 2018 at 12:41, Rene Hopf  wrote:
>> 
>>> However, I could not even find coding style guidelines.
>> 
>> http://linuxcnc.org/docs/2.7/html/code/style-guide.html
>> 
>> indentation should be 4 spaces.
> 
> ah. well, tabs are used in a lot of places :D
> pepole already started to remove them form python scripts, but the c code is 
> still a mess.

ramdom pick from control.c
https://seafile.ist-wunderbar.com/f/30d26ddd807d4401a0ae/
wrong, mixed, and misleading.
gcc6 has a -Wmisleading-indentation warning for this.


> 
> I was looking in the contributing file...
> also see: https://github.com/LinuxCNC/linuxcnc/issues/435
> 
>> 
>> -- 
>> 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


--
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] coding style

[Rene Hopf]

> On 4. May 2018, at 13:55, andy pugh  wrote:
> 
> On 4 May 2018 at 12:41, Rene Hopf  wrote:
> 
>> However, I could not even find coding style guidelines.
> 
> http://linuxcnc.org/docs/2.7/html/code/style-guide.html
> 
> indentation should be 4 spaces.

ah. well, tabs are used in a lot of places :D
pepole already started to remove them form python scripts, but the c code is 
still a mess.

I was looking in the contributing file...
also see: https://github.com/LinuxCNC/linuxcnc/issues/435

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

[Emc-developers] coding style

[Rene Hopf]

There is a mix of tabs and spaces in the code, sometimes even mixed in the same 
line,
and loads of bad indentation. Im not blaming anyone here,
that just happens with such an old codebase with so many contributors.

However, I could not even find coding style guidelines.
Imho the only way of fixing that is with some automatic formatter.
I think clang-format is the best: https://clang.llvm.org/docs/ClangFormat.html

I use a makefile taget like this:
https://github.com/rene-dev/stmbl/blob/master/Makefile#L347
the style is in a separate file: 
https://github.com/rene-dev/stmbl/blob/master/.clang-format

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

[Emc-developers] Linuxcnc meeting Stuttgart, Germany 2018

[Rene Hopf]

Hi,
All info here:
https://doodle.com/poll/rrzknkwiaukwgrar

Rene

--
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] RtNet rt-preempt

[Rene Hopf]

> On 4. Apr 2018, at 14:56, theman whosoldtheworld  wrote:
> 
> I've ask to rtNet mailing list too ... but no response yet.
> 
> So I ask to dev. ... RtNet is develop for rtai or xenomai, but somehow try
> to use on rt-preempt kernel .. not now if with success or not.
> 
> If is not possible use RtNet on rt.preempt thesere are some other option
> for realtime ethernet for linux ? (I know and test ethercat, and powerlink
> ... actually I study cc-link IE because big-packet capable, I plan to try
> to use cc-link ie on linux pc).
> These because actually in some plc brand is possible to install custom made
> c11/c14 library and in these manner Use realtime-ethernet is a fast way to
> rt-data-exchange from Lcnc and PLC.
> 
> Actually use rtu-modbus and tcp modbus and ethernet tcp or ethernet ip...
> but is not real time …

with rt-preempt kernel you dont need any of that. you can just assign any 
userspace thread to realtime, so you can use the normal socket api.

> 
> Thanks for all suggest.
> bkt
> --
> 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] in halshow, what are the units of the time display ?

[Rene Hopf]

> On 23. Mar 2018, at 14:41, John Kasunich  wrote:
> 
>> its CPU cycles. 
>> http://linuxcnc.org/docs/2.5/html/hal/basic_hal.html#_hal_components
>> I think that should be changed to some unit of time.
>> 
> 
> Changing to time units may be non-trivial.  We found a long time ago 
> (mid-2000's) that the calls to convert from CPU clocks to nano-seconds were 
> ridiculously slow.  In many cases, it was taking 10 times longer to compute 
> the duration of a HAL function than it took to execute the function itself.  
> And since those HAL pins must be updated for every function call, we just 
> couldn't afford the overhead.

we have exactly the same problem in the stmbl hal implementation.
the way we solved this, is to do all the internal calculation in ticks, and and 
only convert to time when the user reads them.
the downside is, they cant be pins, and that cant be converted in realtime. but 
there is no need. We used to have pins for the time, like in linuxcnc,
now there is a command that displays the last, average and maximum time for 
each function.

Rene
--
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] in halshow, what are the units of the time display ?

[Rene Hopf]

> On 22. Mar 2018, at 17:00, andy pugh  wrote:
> 
>> 
>> When displaying the time used by peal rime tasks, what are the units?  Are
>> they ns, or timer ticks?
> 
> I believe them to be nanoseconds.

its CPU cycles. 
http://linuxcnc.org/docs/2.5/html/hal/basic_hal.html#_hal_components
I think that should be changed to some unit of time.

Rene
--
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] writing new firmware to read yaskawa absolute encoder

[Rene Hopf]

> On 14. Mar 2018, at 17:54, Peter C. Wallace  wrote:
> 
> Typically there would be no issue sending and receiving 7 bit characters with 
> the PacketUART (just mask bit 7 on RX and set it to the line idle (high) 
> state on TX )

thats not how uart works, if there is a stop bit, and usually there is.
--
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] writing new firmware to read yaskawa absolute encoder

[Rene Hopf]

> On 10. Mar 2018, at 08:45, Thắng Lê  wrote:
> 
> When i try run mesa_uart or mesa_pktgyro_test in halcmd, terminal
> shows me "*undefined
> symbol: hm2_uart_read" or " undefind symbol: hm2_pktuart_send" *. Any idea
> why do this happen?

hm2_pktuart_send is provided by 
https://github.com/LinuxCNC/linuxcnc/blob/af15a4d90e1d51d5309db65fe1c9511e486df411/src/hal/drivers/mesa-hostmot2/pktuart.c
you need to load that before you load the others.
--
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] Setting the rtapi debug level

[Rene Hopf]

> On 6. Mar 2018, at 14:09, andy pugh  wrote:
> 
> Am I right in thinking that there is currently no way to alter the
> debug level without recompiling?
> (specifically in uspace)
> 
> We used to be able to write to a file somewhere, but I seem to recall
> that no longer works?
> 
> Is is something that a very simple HAL component could do?

yes and no. I asked the same question a few weeks ago.
According to jepler, some components save the debug level, change it, and then 
change it back.
maybe each component can have a hal parameter to change the debug level?
just like they all have the tmax value…

> 
> -- 
> 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] 64 bit LinuxCNC possible

[Rene Hopf]

> On 18. Feb 2018, at 20:16, Jon Elson  wrote:
> 
> I have built a system running a 64-bit Debian 8 (Jessie), and have the 
> preempt RT kernel running.
> Is it possible to put LinuxCNC (non-simulation) on this?  Is there a 
> pre-compiled binary, or would it
> have to be compiled from source?
> 
> This machine sits right next to my test bench, so it would be handy to be 
> able to test motion control boards directly
> with it.  (Other option is to add YET ANOTHER computer with a 32-bit OS and 
> ssh into it.)

Im running all my machines(and know of some more) with stretch, 64 bit rt 
preempt, and master.
no issues at all.
all various ethernet mesa cards.

> 
> Thanks,
> 
> Jon
> 
> --
> 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] Mode switching bug

[Rene Hopf]

> On 5. Dec 2017, at 10:33, Chris Morley  wrote:
> 
> I actually wonder why the controller must have modes at all.
> 
> The only thing really important is if it is busy it must finish.

removing modes altogether would solve a lot of problems.
especially jogging while paused, which is a much requested feature, and comes 
up very often.
there is a jog while paused branch, which already does most of the stuff, like 
going back to the old position when you continue.


> 
> ie if it's busy running an MDI command it can't jog
> 
> If it's running a program it can't MDI
> 
> etc
> 
> Traditionally NC machines separated these modes with a switch.
> 
> I don't see why we need to do that any more.
> 
> 
> If the controller is idle it should be able to do anything.
> 
> This would leave it to the UI/user to decide whats allowed when.
> 
> 
> UIs have been working around this problem for  a very long time.
> 
> Ie touchoff is an MDI command which is quite obviously a manual
> 
> mode command.
> 
> 
> Chris M
> 
> 
> From: Kurt Jacobson 
> Sent: December 4, 2017 7:27 PM
> To: EMC developers
> Subject: Re: [Emc-developers] Mode switching bug
> 
> Any UI that wants to work well with wheel jogging has to find some way of
> setting the task_mode
> back to manual after each MDI command, and as we have seen that is not
> trivial to do without
> breaking external programs that issue MDI commands. In fact, I do not think
> it is an overstatement
> to say that so far *nobody* has managed to make both wheel jogging and
> external  MDI commands
> work satisfactorily at the same time.
> 
> Since all UIs suffer from this problem, it seem like instead of each UI
> using some kind of work
> around, this problem might should be solved at a lower level.
> 
> I have no idea what MDI mode actually does internally, but from a practical
> user perspective, I can't think
> of any time were there is a need for LCNC to remain in MDI mode after
> issuing an MDI.
> 
> As far as I can tell most UIs that work well with wheel jogging employ
> something like the following pseudo code:
> 
> def issue_mdi(cmd):
>set_mode(MDI)
>issue_mdi(cmd)
>set_mode(MANUAL)
> 
> while(True):
>if not mode_manual and is_idle:
> set_mode(MANUAL)
> 
> So basically the UI ensures that LCNC is not in MDI mode unless it it
> actively issuing an MDI command, which
> essentially is the same thing as not having an MDI mode at all (from the
> users perspective). So what if instead
> of making each UI have to handle switching back to manual mode this is done
> elsewhere. For example `command.mdi()`
> could switch LCNC to mdi mode, issues the command, and then switched back
> to manual.
> 
> It seems like something like this would make life simpler for the UIs ...
> 
> Cheers,
> Kurt
> 
> 
> On Mon, Dec 4, 2017 at 11:43 AM, Kurt Jacobson 
> wrote:
> 
>> On Mon, Dec 4, 2017 at 10:54 AM, Rene Hopf  wrote:
>> 
>>> 
>>>> On 4. Dec 2017, at 16:14, Les Newell  wrote:
>>>> 
>>>> This is master as of a couple of months ago. I'd rather not install the
>>> patch because I want it to switch back to manual after MDI.
>>> 
>>> the patch should still allow you to do that. thats why I asked you to
>>> test.
>>> 
>> 
>> I am afraid not. Dewey's branch does not switch back to manual after an
>> MDI, at least in my tests.
>> 
>> 
> --
> 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] Mode switching bug

[Rene Hopf]

> On 4. Dec 2017, at 16:14, Les Newell  wrote:
> 
> This is master as of a couple of months ago. I'd rather not install the patch 
> because I want it to switch back to manual after MDI.

the patch should still allow you to do that. thats why I asked you to test.


--
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] Mode switching bug

[Rene Hopf]

> On 4. Dec 2017, at 15:17, Les Newell  wrote:
> 
> Using Axis I can't say I have ever had a problem with MDI commands not being 
> executed as reported in issue #361.

are you using master or 2.7? this issue only occurs in master.
can you check if the patch has the desired behaviour for you using master?


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

[Emc-developers] Persistent parameters

[Rene Hopf]

Hi,
currently there seem to be no persistent parameters that are unassigned, and 
are really persistent.
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_array.cc#L182
any particular reason why there is a list, and not just a range, like it says 
in the docs?
the docs say: "The range of persistent parameters may change as development 
progresses. This range is currently 5161- 5390.”

maybe there is another way, but I would like to use that for my tool changer.
On startup the current tool is unknown, indicated by the -1 in current tool.
I would like to load that form a parameter, because the tool does not change 
while the machine is off.
This saves setting the tool using M61.

then, lets suppose I press estop during a tool change.
this can happen any time, and I would like to save what tool is in the spindle.
I could press estop before, during, or after tool change has finished.
in the first 2 cases, the current tool is wrong, and the machine will crash on 
the next tool change, or continue with the wrong tool.

next problem: lets say I pull the plug/something crashes during 
machining/toolchange.
obviously the parameters are not saved in that case.
how about a parameter that indicates that linuxcnc did not shut down properly?

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

[Emc-developers] Mode switching bug

[Rene Hopf]

Hi,
Im working on the mode switching issues:
https://github.com/LinuxCNC/linuxcnc/issues/361
https://github.com/LinuxCNC/linuxcnc/issues/285

I added some debugging output here: 
https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/usr_intf/axis/scripts/axis.py#L936
and it seems that either the mode switch fails, or something immediately 
changes it back to manual.
its not halui, I checked that.
any ideas how I can debug this? can a mode switch fail? what else it setting 
modes?
its not axis, that function does not get called when it changes it back.

Rene
--
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] Asymmetric G33.1

[Rene Hopf]

> On 30. Nov 2017, at 19:54, Chris Morley  wrote:
> 
> Ahh I misunderstood - and obviously didn't look at the code ::)

you dont need to, there is documentation ;D
currently it does not check if you can even go at that speed. but normal g33.1 
also does not do that,
but there is a commit from rob.
It would be cool if a default I vaule could be specified somehow, so you dont 
have to change the post processor to use this feature.

> 
> interesting.
> 
> Chris M
> 
> 
> 
> From: Andy Pugh 
> Sent: November 30, 2017 6:16 PM
> To: EMC developers
> Subject: Re: [Emc-developers] Asymmetric G33.1
> 
> 
> 
>> On 30 Nov 2017, at 17:30, Chris Morley  wrote:
>> 
>> I wonder if things like that (bool options) should be INI setting?
> 
> It’s a scale factor, not a Boolean.
> 
> I can imagine it would vary from hole to hole. (Surface speed down, z-axis 
> speed up)
> -
> --
> 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] Max angular velocity

[Rene Hopf]

> On 16. Aug 2017, at 21:42, Andrew  wrote:
> 
> Hello!
> 
> I'm setting up a hexapod-like multiaxis machine. The problem I encountered
> was joints extending too fast when doing angular rapid motion like G0 A90.
> Joint velocity constraint was violated, so I wanted to decrease max angular
> velocity. The idea that max velocity slider also controls angular velocity
> proved wrong.
> 
> Dewey was so kind to search through the code and figure out that
> [TRAJ]MAX_ANGULAR_VELOCITY is not used for trajectory planner.
> 
> But it would be natural to adjust max angular velocity with a GUI slider just
> like max linear velocity..
> Is it possible at all?

currently not.
the kinematics is behind the planner, and the planner does not obey the joint 
limits.
all the planning is done in cartesian space, and does not care about joints.
https://github.com/LinuxCNC/linuxcnc/issues/97 

> 
> Thanks,
> Andrew
> --
> 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] Linuxcnc meeting in Stuttgart. this weekend

[Rene Hopf]

> On 17. Jul 2017, at 22:10, andy pugh  wrote:
> 
>> On 17 July 2017 at 19:17, Rene Hopf  wrote:
>> 
>> 2013: http://wiki.linuxcnc.org/cgi-bin/wik...g_2013_Germany
>> 2014: http://wiki.linuxcnc.org/cgi-bin/wik...g_2014_Germany
>> 2016: http://wiki.linuxcnc.org/cgi-bin/wik...g_2016_Germany
>> 2016: https://www.flickr.com/photos/147272...57676851103260
> 
> Your URLs seem to have been abbrieviated:
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Integrator_Meeting_2013_Germany
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Integrator_Meeting_2014_Germany
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Integrator_Meeting_2016_Germany
> 
> (I am doing less well with the Flickr one)

Sorry, copy and paste fail.
https://www.flickr.com/photos/147272829@N02/sets/72157676851103260

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

[Emc-developers] Linuxcnc meeting in Stuttgart. this weekend

[Rene Hopf]

Hi,
Im sorry I did not announce this earlier, but there were some difficulty in 
finding a date,
and next weekend was the most popular option.

The meeting will take place in Stuttgart, 21-23.7
http://doodle.com/poll/uxfeiqeqvmcffx8u

Previous events:
2013: http://wiki.linuxcnc.org/cgi-bin/wik...g_2013_Germany
2014: http://wiki.linuxcnc.org/cgi-bin/wik...g_2014_Germany
2016: http://wiki.linuxcnc.org/cgi-bin/wik...g_2016_Germany
2016: https://www.flickr.com/photos/147272...57676851103260

We will bring a demo of STMBL: https://github.com/rene-dev/stmbl

Rene
--
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] Gladevcp_gtk3 Branche

[Rene Hopf]

> On 17. Jul 2017, at 15:21, Chris Morley  wrote:
> 
> I did the work on that branch.Gremlin can not work in gtk3.

I know, and I would like to work on that.
problem is, in in wheezy or jessie shipped with a old gtk3 version, which could 
not ctreate the opengl context without hacks.
in stretch this is possible.

> I did some experimental work on a gremlin substitute...it's was too much work 
> for me to figure out but I could dig up the code when I'm next at home..in a 
> couple weeks.
> I think I got as far as displaying the origin and axis letters , pan as zoom.
> I would love for someone to take this on.
> I quit working on the branch because of this hurdle.

I think the first step would be to merge master into that branch, and get the 
basics working.
can you explain how I can test things?
launching the widgets, and stuff, unfortunately I dont know much about pyvcp…

I think getting rid of gtk2 dependencies is an important step to remove legacy 
deps, and move forward...

Rene
--
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] Gladevcp_gtk3 Branche

[Rene Hopf]

Hi,
Im picking up this issue, because debian stretch was released, and it includes 
a up to date version of gtk3, which allows to create a opengl context.
this example code works on stretch: 
https://stackoverflow.com/questions/42598360/no-glcontext-for-gtkglarea-in-gtk3-python
there is already some work on gtk3: 
https://github.com/LinuxCNC/linuxcnc/compare/gladevcp_gtk3
merging this into master gives a few conflicts, and I cant get it to work.
I would like to port gremlin to gtk3, but I need some place to start, like a 
minimalistic gui example that uses gtk3 and imports gremlin.
Norbert mentioned that it would be no problem to port the widgets.

Rene


> On 15. Feb 2016, at 20:02, Rene Hopf  wrote:
> 
>> 
>> On 10 Feb 2016, at 06:22, Chris Morley  wrote:
>> 
>> 
>> 
>>> From: reneh...@mac.com
>>> Date: Tue, 9 Feb 2016 23:59:03 +0100
>>> To: emc-developers@lists.sourceforge.net
>>> Subject: [Emc-developers] Gladevcp_gtk3 Branche
>>> 
>>> Hi,
>>> Norbert asked me to look into porting gremlin to gtk3. He pointed out that 
>>> someone already started. Does anyone know what the status is? What already 
>>> works and what doesn't? Any issues in particular?
>>> 
>>> Rene
>>> 
>>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/gladevcp_gtk3
>> 
>> The opengl libraries used in gremlin have not been ported to gtk3, so 
>> different 
>> ones need to be used.
> 
> Yes, I did see that. gtkglext seems to be ported to gtk3, but is already 
> deprecated. https://github.com/tdz/gtkglext
> the proposed method of creating is gtkglarea 
> https://developer.gnome.org/gtk3/stable/GtkGLArea.html
> but that requires gtk3.16 which does not come with jessie, or wheezy.
> the thing you found hacks directly into X, which is really not a way I would 
> like to go.
> look at this line:
> xlib = cdll.LoadLibrary('libX11.so')
> I can’t believe there is no sane way of creating an OpenGL context in gtk.
> 
>> 
>> The only workable example code I could find was in this :
>> http://www.digitaloctave.com/tags/gtk3.htm
>> 
>> I have my opengl experimental code on a laptop some where I could dig up.
>> I didn't push the work because I was not sure if the licence was ok nor 
>> whether this code was the way to go.
>> I'm also not an opengl coder, I just hack till things work.
>> 
>> As for the rest of the widgets, They are mostly converted to work with gtk3.
>> In fact the plan was for gladevcp to use either gtk2 or gtk3 depending on 
>> what
>> was available.
>> It still uses the GLADE-gtk2 editor - hopefully no issue to change that.
>> I couldn't get Embedding to work in gtk3, at least in the way it was coded 
>> originally.
>> Themeing doesn't work.
>> 
>> Other then that, things are great
>> 
>> Chris M
>> 
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
>> ___
>> 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

[Emc-developers] back tool lathe

[Rene Hopf]

Hi,
Im working on this issue: https://github.com/LinuxCNC/linuxcnc/issues/178
I got it working, by forcing axis into y2 view, and disable the x invert.
the remaining issue is the tool preview, which does not work in y2 mode.
also, the grid does not seem to work in y2.
but I could not find where the preview is generated, can anyone point me in the 
right direction?
I also propose a change to the ini file:
use BACK_TOOL_LATHE = 1 like gmoccapy for back tool lathes.

Rene
--
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] RTNET servo drive

[Rene Hopf]

Hi,
Interesting Project!
Im also working on a servo amp which supports hiperface, mitsubishi abs 
encoders, and many other protocols, and also resolvers.
https://github.com/rene-dev/stmbl
this is the mistubishi encoder code: 
https://github.com/rene-dev/stmbl/blob/newstuff-v4/src/comps/encm.comp
currently we use smartserial as command via a mesa card, but we a also working 
on a ethernet version.
the idea is some udp based protocol like the mesa cards use, but that is still 
in development.
at the moment we are working to get version 4 of our hardware working, a lot of 
code needs to be done.
https://www.dropbox.com/s/axa2u1sy6j62hp7/2016-12-13%2001.57.41.jpg?dl=0
https://www.dropbox.com/s/h2sby9pc4mfvdv8/2016-12-13%2001.57.27.jpg?dl=0
https://www.dropbox.com/s/citvmronmz9ryrt/2016-12-10%2021.12.50.jpg?dl=0
some projects powered by stmbl:
https://www.youtube.com/watch?v=wXLcAZwjlzE
https://www.youtube.com/watch?v=gwgnAeGjZrA
https://www.youtube.com/watch?v=uMytcf41GPU
https://www.youtube.com/watch?v=pMZQ4q7iM20

Rene

> On 05 Feb 2017, at 15:37, mark.vandoesb...@hetnet.nl wrote:
> 
> I've been working on an ethernet controlled servo drive for some time now.
> This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
> The current control loop is on the drive, but the position control loop
> is on the PC.
> 
> Currently only tree motor types are supported, being Mitsubishi MF-S13
> Mitsubishi HC-PQ-[24]3 and the Osai DS-56.  The Osai motor uses a
> Hiperface encoder, so supporting another motor with Hiperface should be
> a simple change of the encoder offset and number of poles.
> 
> Since the drives have to be synchronised to the PC it is important to
> reduce the jitter to the drives. To do this I have made two modifications
> to the uspace_xenomai interface. The first is that a posix timer is used
> to generate the control frequency. The second is that the real-time
> synchronisation function needs access to this timer. (Eventually this
> has to be replaced by PTP)
> 
> Another change has to do with permissions, I'm not sure what the proper
> fix is so there's a hack in there to do everything as root.
> 
> The sources for the drive are at: 
> https://github.com/mark-v-d/motor_control.git
> 
> The patched linuxcnc version is at:
> https://github.com/mark-v-d/linuxcnc.git
> 
> Please keep in mind this is all work in progress. The hardware needs
> a few patches (notes in the schematic) and the software is nowhere near
> complete. As soon as I've got everything working I'm going to make another
> drive which works at 600V, and support at least the AEAT-6010/6012
> and AEAT-9000-1GSH1 encoders.
> 
> regards,
> 
> Mark.
> 
> --
> 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] Absolute homing with single-turn encoders.

[Rene Hopf]

> On 4 Jan 2017, at 19:07, Nicklas Karlsson  
> wrote:
> 
> As I understand it position is already known from absolute encoder so there 
> is no need to run machine to a switch is hit?

there are generally 2 types of abs encoders: multiturn and non multiturn.
non multiturn encoders only give the absolute position to 0-360 deg, so one 
shaft revolution.
if you turn it 5 times, the encoder cant tell without power.
multiturn encoders usually have a battery backup, and can count multiple turns 
when powered off.
with multiturn encoders its really easy, you just have a fixed offset to your 
home position, and it just works.
the idea is to use non multiturn encoders in a multitun way, so you just have 
to remember on which rotation the servo is, but not where on that rotation.
so when you assume your motors dont turn more than a full revolution while the 
machine is powered off, you can just use the abs position, and full revolutions 
to work out the exact position.
of course this also works with resolvers.

> 
> 
> On Mon, 2 Jan 2017 22:00:41 +
> andy pugh  wrote:
> 
>> Due to the lack of an M3 die that actually cuts a thread, and the fact
>> that none of the places that sell dies on a bank holiday sell dies of
>> a quality that I feel like buying, I spent today trying to make my
>> lathe home without moving. (with a complicated setup on the lathe,
>> maybe including a steady-rest, this can be a good feature)
>> 
>> The idea is that by saving the machine position to file I can then use
>> the absolute single-turn resolver position for fine-position
>> determination and the saved position to work out how many full turns
>> need to be added to that.
>> 
>> Adding the resolver position to the full-turns position gives me a
>> value that I can pass to motor-pos-fb (and, it turns out, pid.fb) such
>> that when the "home" button is pressed with HOME_ABSOLUTE_ENCODER = 2
>> set in the INI (a new feature, thanks Dewey) the machine adopts the
>> current position as the true position.
>> 
>> I do this with a user-space python component (as it needs file system
>> access) and it writes its own little file.
>> 
>> I am trying to determine if I can use the existing position.txt file.
>> The file itself is ideal, my file ends up with exactly the same data,
>> but I think that if that file exists then the values are copied
>> directly into joint.N.motor-offset and that isn't _quite_ what I need.
>> 
>> -- 
>> 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


--
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] Absolute homing with single-turn encoders.

[Rene Hopf]

Im interested in this application as well.
my initial idea was to generate an index signal, and home to index.
on stmbl I can generate an index for any feedback system(resolver, abs 
encoder,...), and pass it to linuxcnc via smartserial.
but as the positioning works on abs motor position anyway, it would me much 
easier to save the multiturn value, or set some fixed offset on homing. do you 
have the python script uploaded somewhere?

Rene

> On 2 Jan 2017, at 23:00, andy pugh  wrote:
> 
> Due to the lack of an M3 die that actually cuts a thread, and the fact
> that none of the places that sell dies on a bank holiday sell dies of
> a quality that I feel like buying, I spent today trying to make my
> lathe home without moving. (with a complicated setup on the lathe,
> maybe including a steady-rest, this can be a good feature)
> 
> The idea is that by saving the machine position to file I can then use
> the absolute single-turn resolver position for fine-position
> determination and the saved position to work out how many full turns
> need to be added to that.
> 
> Adding the resolver position to the full-turns position gives me a
> value that I can pass to motor-pos-fb (and, it turns out, pid.fb) such
> that when the "home" button is pressed with HOME_ABSOLUTE_ENCODER = 2
> set in the INI (a new feature, thanks Dewey) the machine adopts the
> current position as the true position.
> 
> I do this with a user-space python component (as it needs file system
> access) and it writes its own little file.
> 
> I am trying to determine if I can use the existing position.txt file.
> The file itself is ideal, my file ends up with exactly the same data,
> but I think that if that file exists then the values are copied
> directly into joint.N.motor-offset and that isn't _quite_ what I need.
> 
> -- 
> 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] Gladevcp_gtk3 Branche

[Rene Hopf]

> On 10 Feb 2016, at 06:22, Chris Morley  wrote:
> 
> 
> 
>> From: reneh...@mac.com
>> Date: Tue, 9 Feb 2016 23:59:03 +0100
>> To: emc-developers@lists.sourceforge.net
>> Subject: [Emc-developers] Gladevcp_gtk3 Branche
>> 
>> Hi,
>> Norbert asked me to look into porting gremlin to gtk3. He pointed out that 
>> someone already started. Does anyone know what the status is? What already 
>> works and what doesn't? Any issues in particular?
>> 
>> Rene
>> 
>> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/gladevcp_gtk3
> 
> The opengl libraries used in gremlin have not been ported to gtk3, so 
> different 
> ones need to be used.

Yes, I did see that. gtkglext seems to be ported to gtk3, but is already 
deprecated. https://github.com/tdz/gtkglext
the proposed method of creating is gtkglarea 
https://developer.gnome.org/gtk3/stable/GtkGLArea.html
but that requires gtk3.16 which does not come with jessie, or wheezy.
the thing you found hacks directly into X, which is really not a way I would 
like to go.
look at this line:
xlib = cdll.LoadLibrary('libX11.so')
I can’t believe there is no sane way of creating an OpenGL context in gtk.

> 
> The only workable example code I could find was in this :
> http://www.digitaloctave.com/tags/gtk3.htm
> 
> I have my opengl experimental code on a laptop some where I could dig up.
> I didn't push the work because I was not sure if the licence was ok nor 
> whether this code was the way to go.
> I'm also not an opengl coder, I just hack till things work.
> 
> As for the rest of the widgets, They are mostly converted to work with gtk3.
> In fact the plan was for gladevcp to use either gtk2 or gtk3 depending on what
> was available.
> It still uses the GLADE-gtk2 editor - hopefully no issue to change that.
> I couldn't get Embedding to work in gtk3, at least in the way it was coded 
> originally.
> Themeing doesn't work.
> 
> Other then that, things are great
> 
> Chris M
> 
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Gladevcp_gtk3 Branche

[Rene Hopf]

Hi,
Norbert asked me to look into porting gremlin to gtk3. He pointed out that 
someone already started. Does anyone know what the status is? What already 
works and what doesn't? Any issues in particular?

Rene

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=shortlog;h=refs/heads/gladevcp_gtk3
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] jerk limited trajectory

[Rene Hopf]

Hi,
Are there any plans on jerk limitation? During my research I found this:
https://github.com/cnc-club/linuxcnc/commit/c7f6861909a6e2e491d38059a1b7d26d91f4a8a0
 

Has anyone ever seen or even tested this?

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

Re: [Emc-developers] Emc-developers Digest, Vol 114, Issue 13 (Ethernet, STM32F407)

[Rene Hopf]

> 
> I use the STM32F407 with the hostmot2 driver. I had some glitches at startup 
> but today I added a small delay someone here suggested end then startup works 
> perfect every time with two cards connected.
> 
> I have been running two axes with DC servo motors and ordinary encoders on 
> one of the cards although both cards should be used to get 4 axis. I ran 
> servo loop at 1kHz but expect somewhat faster will also work.

Hi, currently I am working on a similar project involving a ethernet based 
board to control my own servo drives: https://github.com/rene-dev/stmbl
Is anyone of you willing to share some code? I already started implementing a 
server for the hm2_eth protocol, but maybe we can work together?
my idea is to use rs485 to control the drives, as it is much better than 
step/direction.
the stmbl hardware also supports smart serial, but there is a lot of software 
to do.
is there any smartserial client code available?

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

Re: [Emc-developers] Remote Display

[Rene Hopf]

On 06 Oct 2014, at 17:39, Kirk Wallace  wrote:

> On 10/06/2014 08:17 AM, Jon Elson wrote:
> ... snip
>> on-screen response.  There probably is a way to get ssh to
>> not encrypt the transfers,
>> which should speed things up a bit.
> ... snip
> 
> It seems the whole point of SSH (Secure SHell) is to encrypt data. I 
> seem to recall the reason for tunneling is to get the data through SSH. 
> Which makes me think one could dispense with SSH and tunneling.
> 
> I also seem to recall an NML file that could route NML traffic to a 
> remote IP address.

I found this: http://www.wallacecompany.com/machine_shop/EMC2/remote_notes.html

But I could not find anything about Machinekit supporting remote GUIs.

> 
> But the above is off-hand, so add salt to taste.
> 
> 
> -- 
> Kirk Wallace
> http://www.wallacecompany.com/machine_shop/
> http://www.wallacecompany.com/E45/
> 
> --
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Remote Display

[Rene Hopf]

Hi,
I am wondering how difficult it would be to have a remote display.
I know linuxcnc can run headless, but how to interact with it?
It would be nice to have the realtime stuff on a embedded device, like the 
beagleboard,
and Axis running on my Desktop.
X11 forwarding does not really work with OpenGL, and vnc is way to slow…
Although digging in the src, I do not quiet understand how the GUI interacts 
with the RT stuff.(other than that it is SHM)
I think the first step to get going would be some sort of a standalone version 
of axis,
and something like a tcp/ip hal bridge…

I think it would be very useful for desktop mills and printers.

Rene 
--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] xhc-04 pendant with 2.6.1 and wheezy boot iso

[Rene Hopf]

On 06.08.2014, at 16:09, David Armstrong  wrote:

> guy's
> 
> this is using the new cd out the box and no changes
> logging in as user and selecting linuxcnc , and sim xhc pendants give
> access permissions
> error . i presume the usb is not part of the users group
> 
> running root terminal and then selecting as before xhc pendant works
> 
> i would have thought as a user if linuxcnc works then the usb should or
> would be active
> at this stage
> 
> i may add this is not me using run in place , this is as the hybrid iso is
> presented to a new install
> 
> are we missing a required permission
> 

Its missing the udev rule:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Using_A_XHC-HB04_Wireless_MPG_Pendant

> Dave
> --
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers