Re: [Emc-developers] How closely do we need to adhere to the NIST standard?

[Nicklas SB Karlsson]

There might be requirements for safety reasons but do not think we need to care 
about some standard require MDI commands
to be executed only with a physical button.

For safety reasons I have a safety relay connected to physical buttons. Then 
power is turned off and energy stored
stored in capacitors have been consumed computer can't start the machine even 
if it want to.

Nicklas Karlsson


tis 2024-04-09 klockan 13:59 +0100 skrev andy pugh:
> Apart from anything else, I am not sure that it is a standard.
> 
> This is based on bug report #2956. Our current behaviour does not match the
> NIST RS274 interpreter "report" from 2000.
> 
> The last actual "RS" standard (ie the RS in RS274) was issued in the 1970s.
> There is an ISO standard from 1982, and then the NIST EMC report from 2000.
> 
> My own feeling is that any deliberate deviation from the NIST v3 report is
> not a "bug" as such, and that perhaps we should simply close the "bug" as a
> "feature".
> 
> Has anyone else looked at this bug report? What do you think?
> 
> https://github.com/LinuxCNC/linuxcnc/issues/2956
> 




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

Re: [Emc-developers] IGBT Module Dial-a-Yield Project Ideas

[Nicklas SB Karlsson]

fre 2024-04-05 klockan 06:55 -0400 skrev Curtis Dutton:
> Hello all,
> 
> I'm starting a new project to build a motor drive based upon igbt modules.
> Hoping to build something that has a single type of controller that will
> plug and play with various capacity igbt modules for various size motors.
> 
> This thing shall be able to act as either a vfd or servo drive.
> 
> I know this has been discussed before and it's time to get this idea going.
> I'm tired of trying to source drives and vfds and having to learn how to
> operate, integrate and maintain all these different devices, when they are
> all functionally identical. (not to mention thay they are opaque and closed
> source)
> 
> I'm starting out part of my investigation using a pine64 board. It's
> risc-v based soc with 2 ethernet ports, wifi, bluetooth etc... I'm going to
> initially interface it as an ethercat "device"
> 
> My first step is to get linux cnc running on it and go from there.
> 
> Does anyone have experience with anything risc-v related? Tips, advice,
> resources pretty much any pointers are welcome to help me get up to speed
> faster.
No experience with anything risc-v realated but do not think this matter as 
software is usually written in C or maybe
C++ and compiler take care of the translation to CPU instructions. As a note I 
would personally prefer ADA instead of C
or C++ but is not very important.

Do however have experience and theorethical knowledge about electric motors. 
Also some knowledge and experience with
Ethercat and CANopen used both over ethercat and ordinary CAN network.


Nicklas Karlsson



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

Re: [Emc-developers] Part of my problem with this program

[Nicklas SB Karlsson]

> ...
> The theory is that even a bent spindle is effectively a perfect circle 
> if it is rotating faster than the servo loop

Diameter?

Nicklas Karlsson



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

Re: [Emc-developers] Part of my problem with this program

[Nicklas SB Karlsson]

tor 2024-03-07 klockan 21:26 -0500 skrev gene heskett:
> Greetings all;
> 
> one of the problems I am having when using a reasonable speed to search 
> for the edge of a hole is that it does not stop fast enough on first 
> contact, and leaves the probe touching the side of the hole as it spins 
> often enough I get a probe tripped on the next move which recenters the 
> probe so it can find the next side of the hole.
> Since the move in all cases is one to open the probe contact, which a 
> .1mm move will do, is there a way to make it ignore such a false trigger 
> during the first few milliseconds of the back to center move? Like 
> disabling the probe input when its not a z move after a g38.2 probe move?

Sometimes have or had a similar problem. Guess a good solution would be a 
distance then moving away from work piece.

I have .ngc files to touch off in different directions. Looking into my .ngc 
files for this there first are G38.n move
to probe then probe input is turned off before moving back. Thinking about 
again this is not a perfect solution, a
better option would be to only turn off temporary until part is cleared with 
some margin but until moved back to start
point should not be a problem.

To normally have probe turned on should be a good idea to avoid jogging into 
work piece by misstake, consider this a bug
in my .ngc I found then i should write answer for you. Have sometimes seen 
probes with broken tip for sale.


Regards Nicklas Karlsson



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

Re: [Emc-developers] Looking for rtapi_shmem example between RT- C comp and Uspace Python comp?

[Nicklas SB Karlsson]

fre 2023-11-17 klockan 20:47 + skrev andy pugh:
> On Fri, 17 Nov 2023 at 19:29, Rod Webster 
> wrote:
> 
> > Finally, I might add that if you are competent in C and the core of
> > your requirement is real time, why complicate it by adding a non-
> > real
> > time Python component. it sounds like the new HAL port feeding
> > external offsets would do the job in C and in Real time.
> 
> The input data is (probably) read from a file, and the realtime
> components don't have file access (except, potentially, to the
> contents of /lib/firmware)

Guess you should start with the streamar. It read from the input and
send to a hal pin.

Nicklas Karlsson



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

[Nicklas SB Karlsson]

Agree. Consider type checking in general as something good. Some errors 
may be discovered before program is run because pieces simply do not fit 
together. In the best cases a valid output is also produced for all 
possible inputs and runtime errors never happen.


Nicklas Karlsson


Den 2023-10-12 kl. 16:01, skrev Chris Morley:

I assume one drawback/advantage is after the change if a component really 
expects an unsigned range the user can easily connect a signed component and it 
might take a while to find that bug.



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2023-10-12 1:57 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] RFC: Reduce number of HAL pin types.

On Thu, 12 Oct 2023 at 04:05, Chris Morley  wrote:
.

I assume you would use a feature branch to start anyways, so we could see what 
problems crop up and assess.

Yes, this is definitely not something to drop straight into master.  (or 2.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, 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] RFC: Reduce number of HAL pin types.

[Nicklas SB Karlsson]

Den 2023-10-11 kl. 21:31, skrev Rod Webster:

In fact, in your sample code, the unsigned int Word _can't_ be being
used as a HAL pin, as it's a simple int, not a pointer.

The code I shared was a typedef. But yes, the pins are created with
hal_pin_new*() so it would seem OK
The hal types do seem to be a well kept secret. How about documenting
them in the hal component generator documentation?
https://linuxcnc.org/docs/devel/html/hal/comp.html#_definitions


The EtherCAT drive doesn't interface directly to HAL, does it? The
actual register size transmitted down the wires is defined in the
ethercat driver.

Andy the ethercat driver was written a long time ago and it's no
longer actively maintained from what I have observed. Yet it's used by
many many users and use of ethercat has been growing among our user
base. I've made some minor changes to it so it can be shared  via a
repository. Whether or not it would break with the proposed changes
would remain to be seen. I certainly would not profess to have the
skills to modify it if that were required.  So who is going to
maintain it? How many other drivers could be affected by your proposed
changes?
Also made a simple Ethercat driver using SOEM. Currently try to add one 
or two operations to FreeCAD CAM module, need to figure out a good 
method to measure parameters that should be equal to estimation of 
parameters in an auto regressive process of order one, a few other 
hopefully minor technical problems to solve and a few parts to 
manufacture. Though will hopefully quite soon return back to the 
Ethercat driver.


Nicklas Karlsson



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

[Nicklas SB Karlsson]

Den 2023-10-11 kl. 12:13, skrev andy pugh:

On Wed, 11 Oct 2023 at 10:58, Nicklas SB Karlsson  wrote:


Have programmed for many years and some programming languages have quite
hard check if data types fit together and think this in general is a
good feature.

And I have programmed _HAL_ for over 10 years, and so think that in
this case there will probably not be many problems.

One example of a useful simplification is that the pin
motion.motion-type has an output type of S32. The most common
components that you might want to connect this to are are "enum" and
"bitslice", both of which require an unsigned input.

S64 has more than enough bits to cover both situations.

I say you could use large numbers on inputs and allow automatic type 
casting if fit inside but not the opposite.



Nicklas Karlsson



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

[Nicklas SB Karlsson]

Den 2023-10-11 kl. 11:54, skrev andy pugh:

On Wed, 11 Oct 2023 at 10:24, Rod Webster  wrote:

How would that work when you need to match a pin type with an external data
structure?

In most cases it will just work. Possibly with unused higher-order bits.

Unless anything is _relying_ on overflow, there shouldn't be any
difficult fixes.


Encoders are commonly used in Linuxcnc and do overflow. However not sure 
if this i a big problem since it fit inside a double.


Then there is for example a double output a unsigned or signed 16 bit 
input to a servo drive there is a problem that must be handled. Same 
apply for digital outputs. There will also be a need to map these into 
PDOs if using CANopen.


Programmed for many years and it is a lot harder to work with dynamic 
unknown data types. Numbers with unknown range is also a little bit 
harder to work with and in particular must be some method to handle the 
case then number is outside expected or valid range.



Nicklas Karlsson



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

[Nicklas SB Karlsson]

Agree, you really have consult widely on that.

Have programmed for many years and some programming languages have quite 
hard check if data types fit together and think this in general is a 
good feature. Some programming languages allow defining sub types for 
example restrict range and even define new types for example for current 
measurement so that it is not accidentally mixed with other signal. To 
define a datatype with restricted range so that it fit inside a signed 
number may be useful for unsigned numbers then cast to a signed number 
is known to always work without an error or exception.



In some cases a datatype is a subset of another datatype so this 
datatype will always fit inside the other. Allow automatic typecasting 
in this case might be an option?


A double as input will "swallow" most other numbers so might in this 
case be a good idea for inputs.



Nicklas Karlsson



Den 2023-10-11 kl. 11:09, skrev andy pugh:

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




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

Re: [Emc-developers] Where to put a file?

[Nicklas SB Karlsson]

tis 2023-06-06 klockan 17:25 +0100 skrev andy pugh:
> On Tue, 6 Jun 2023 at 17:21, Nicklas SB Karlsson  wrote:
> 
> > > However there is a C template (mesa_modbus.c) that is needed, and
> > > I
> > > don't know where that should live. Possibly in /share/ ?
> > In the source tree there other thing live for example
> > src/hal/components is there I added stuff.
> 
> The file is in the source tree in src/hal/drivers/mesa-
> hostmot2/modbus
> 
> However, it needs to exist in the Debian _package_ not just the
> source
> tree, in the same way as halcompile does.
> 
> And to find its way into the package it needs a home in the run-in-
> place tree.
Look there the compiled object or library file end up?



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

Re: [Emc-developers] Where to put a file?

[Nicklas SB Karlsson]

tis 2023-06-06 klockan 00:21 +0100 skrev andy pugh:
> I am trying to add the mesa_modbus framework into the build, targeted
> for linuxcnc-dev
> 
> I think it is fairly clear the executable Python file "modcompile"
> should be parked in linuxcnc-dev/bin and then installed to /bin
> 
> However there is a C template (mesa_modbus.c) that is needed, and I
> don't know where that should live. Possibly in /share/ ?
In the source tree there other thing live for example
src/hal/components is there I added stuff.

Maybe also need to add stuff to makefile or other similar files. Once
figured out directory search files without postfix for example with
grep command to see there filenames are mentioned is how I have done
it.

Nicklas Karlsson



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

[Nicklas SB Karlsson]

sudo ldconfig

?

tor 2023-05-25 klockan 03:52 + skrev Alec Ari via Emc-developers:
> Hi everyone,
> 
> I have built the Gentoo image for LinuxCNC, real-time kernel and all
> with WiFi+wired ethernet support for many of the common USB NICs but
> now running into trouble building LinuxCNC itself:
> 
> `make -j17`:
> 
> config.status: creating ../scripts/setup_designer
> 1 warning generated.
> Creating shared library liblinuxcnchal.so.0
> Linking rtapi_app
> 1 warning generated.
> Syntax checking python script halcompile
> Linking liblinuxcnc.a
> tooldata: depends: objects/emc/tooldata/tooldata_mmap.o
> objects/emc/tooldata/tooldata_common.o
> objects/emc/tooldata/tooldata_db.o
> tooldata: Linking: libtooldata.so.0
> Linking linuxcnc_module_helper
> Linking python module _togl.so
> Linking python module lineardeltakins.so
> clang++ -std=gnu++17 -L/home/ntu/linuxcnc/lib -Wl,-
> rpath,/home/ntu/linuxcnc/lib -ltirpc   -shared -o
> ../lib/python/lineardeltakins.so
> objects/emc/kinematics/lineardeltakins.o -lboost_python311
> Copying python script halcompile
> Linking python module rotarydeltakins.so
> Linking ../rtlib/boss_plc.so
> clang++ -std=gnu++17 -L/home/ntu/linuxcnc/lib -Wl,-
> rpath,/home/ntu/linuxcnc/lib -ltirpc   -shared -o
> ../lib/python/rotarydeltakins.so
> objects/emc/kinematics/rotarydeltakins.o -lboost_python311
> Linking ../rtlib/debounce.so
> Linking ../rtlib/encoder.so
> Linking ../rtlib/enum.so
> 1 warning generated.
> grep: (standard input): binary file matches
> 1 warning generated.
> grep: (standard input): binary file matches
> grep: (standard input): binary file matches
> Linking ../rtlib/counter.so
> grep: (standard input): binary file matches
> Linking ../rtlib/encoder_ratio.so
> Linking ../rtlib/stepgen.so
> ld.lld: error: objects/boss_plc.ver:4: ; expected, but got
> > > > @;
> > > >   ^
> ld.lld: error: objects/debounce.ver:4: ; expected, but got
> > > > @;
> > > >   ^
> ld.lld: error: objects/encoder.ver:4: ; expected, but got
> > > > @;
> > > >   ^
> clang-16: error: linker command failed with exit code 1 (use -v to
> see invocation)
> Linking ../rtlib/lcd.so
> grep: (standard input): binary file matches
> clang-16: error: 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:1231: ../rtlib/boss_plc.so] Error 1
> make: *** Waiting for unfinished jobs
> 1 warning generated.
> make: *** [Makefile:1234: ../rtlib/debounce.so] Error 1
> make: *** [Makefile:1234: ../rtlib/encoder.so] Error 1
> grep: (standard input): binary file matches
> 1 warning generated.
> grep: (standard input): binary file matches
> grep: (standard input): binary file matches
> 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.
> 
> Adding `-v` to LDFLAGS gives me:
> 
> Reading 262/262 realtime dependency files
> Done reading realtime dependencies
> Linking ../rtlib/abs.so
> grep: (standard input): binary file matches
> clang version 16.0.4
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/lib/llvm/16/bin
> Configuration file: /etc/clang/clang.cfg
> System configuration file directory: /etc/clang
> Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/13
> Candidate multilib: .;@m64
> Selected multilib: .;@m64
>  "/usr/lib/llvm/16/bin/ld.lld" --hash-style=gnu --eh-frame-hdr -m
> elf_x86_64 -shared -o ../rtlib/abs.so /usr/lib/gcc/x86_64-pc-linux-
> gnu/13/../../../../lib64/crti.o
> /usr/lib/llvm/16/bin/../../../../lib/clang/16/lib/linux/clang_rt.crtb
> egin-x86_64.o -L/home/ntu/linuxcnc/lib -L/usr/lib/gcc/x86_64-pc-
> linux-gnu/13 -L/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../lib64
> -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-
> gnu/13/../../../../x86_64-pc-linux-gnu/lib -L/lib -L/usr/lib -rpath
> /home/ntu/linuxcnc/lib -ltirpc --version-script 

Re: [Emc-developers] LinuxCNC gathering in Norway

[Nicklas SB Karlsson]

Have been to Norway before and will not come back.

lör 2023-04-29 klockan 14:57 +0200 skrev Petter Reinholdtsen:
> [Andy Pugh]
> > I can probably make it that weekend, but don't want to commit just
> > yet. (I
> > haven't looked at travel options yet)
> 
> Great to hear.  I placed your name on the "maybe' list in the PAD. :)
> 




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

[Emc-developers] Config files, space in path name does not work anymore

[Nicklas SB Karlsson]

Discovered space in path name for tooledit stoped working. Pretty sure
it happened not more than a few months ago. No big deal, just removed
space and it works again but guess it's supposed to work. Trace below,
it first try to read first part before space as a file and then the
part  after the space as a file.

May help to track it down further if needed?

md5sum: /home/karlnick/linuxcnc/configs/by_machine/Modig: Filen eller
katalogen finns inte
md5sum: MD6000/tool.tbl: Filen eller katalogen finns inte
while executing
"exec md5sum /home/karlnick/linuxcnc/configs/by_machine/Modig
MD6000/tool.tbl"
("eval" body line 1)
invoked from within
"eval exec md5sum $::te(filename)"
(procedure "watch" line 12)
invoked from within
"watch start"
invoked from within
"if [file exists $::te(filename)] {watch start}"
(procedure "::tooledit::tooledit" line 65)
invoked from within
"::tooledit::tooledit $filename $columns"
invoked from within
"if ![info exists ::te(top)] {
# expect ::argv == [colname colname ...] filename
set columns "" ;# default use all columns
set argct [lleng..."
(procedure "standalone_tooledit" line 14)
invoked from within
"standalone_tooledit"
(file "/home/karlnick/linuxcnc/bin/tooledit" line 3)




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

[Emc-developers] Sampler, stop sampling at negative on flank?

[Nicklas SB Karlsson]

Have added to halsampler so that it stop sampling at negative enable
flank. This is useful then it is not known how long the sequence is and
gives a method to stop sampler from g-code if it is connected to a
digital output in motion module.

Want to see what other people think about it?


Nicklas Karlsson



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

Re: [Emc-developers] HAL shared memory and the mis-use of hal_malloc

[Nicklas SB Karlsson]

mån 2023-03-27 klockan 00:26 +0100 skrev andy pugh:
> I am working on a HAL driver at the moment, and have started to be
> concerned about mis-use(?) of hal_malloc.
> 
> Looking at the hostmot2 code the data structures are carefully split
> into
> HAL pins and other data. The HAL pins parts are hal_malloc-ed and the
> data
> parts are rtapi_kmalloc-ed (which is just plain malloc in uspace)
> 
> Other components are more lazy, mux_generic for example, and even
> stepgen.c
> hal_malloc the entire data structure.
> 
> Possibly this is why we have reports of users running out of hal
> memory. It
> may not be that they have reached the maximum number of pins (which
> is
> rally rather a lot) but that the supporting data has eaten it up.
If I remember correct it is relatively simple to increase amount of hal
memory.



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

Re: [Emc-developers] Show used tools for loaded NC program?

[Nicklas SB Karlsson]

Fantastic, it is already there.

lör 2023-01-14 klockan 23:13 + skrev Chris Morley:
> Ok I pushed this work to linuxcnc 2.9/master
> AXIS Qtdragon/hd and Qtaxis now will display the tool change numbers
> with the gcode properties
> Gremlin/Gladevcp was missing the gcode properties code all together
> so I added it.
> GMoccapy could tap into this with GStat messages but I didn't go that
> far to add the capability.
> One oddity is AXIS shows tool 0, the rest don't. I'd guess AXIS sets
> yool 0 by default somewhere.
> 
> Not sure if Basicprobe use glcanon.py but if it does canon.tool_list
> will give a list of found tools.
> 
> Chris
> 
> From: Chris Morley 
> Sent: January 14, 2023 1:47 AM
> To: EMC developers 
> Subject: Re: [Emc-developers] Show used tools for loaded NC program?
> 
> I have this working (tool list gcode properties) in principle.
> It's a small change in glcanon.py:
> 
>     def change_tool(self, arg):
>     self.first_move = True
>     try:
>     self.tool_list.append(arg)
>     except Exception as e:
>     print(e)
> Then requires an screen that looks for gcode properties to look for
> the tool list.
> 
> is anyone else working on this? If not I will try to get to it this
> week end.
> 
> Chris
> 
> From: Small Shop Concepts 
> Sent: January 14, 2023 12:32 AM
> To: EMC developers 
> Subject: Re: [Emc-developers] Show used tools for loaded NC program?
> 
> If i do not have a tool in my carousel i get an error stating the
> tool not
> in the carousel and the program wont start. It runs through and
> checks i am
> guessing at cycle start.  I used to have an issue where if i called a
> tool
> twice with a different tool between it would error because it was not
> accounting for returning the tool to the carousel.
> 
> I  do like the idea of having the tool list read at program load and
> displayed somewhere on the gui for those who do not have cam that
> prints
> the tool list in the gcode file.
> 
> 
> 
> On Fri, Jan 13, 2023, 4:59 PM Nicklas SB Karlsson  wrote:
> 
> > Looking into file generated by post processor I used it does not
> > print
> > a list of tools used.
> > 
> > It is easy to miss one and then program in best case quit then row
> > to
> > insert tool is reached, not a big problem but still annoying. In
> > best
> > case it would also check if tool is in tool table, this check
> > should
> > work if each tool get a unique number.
> > 
> > Nicklas Karlsson
> > 
> > 
> > fre 2023-01-13 klockan 16:39 -0500 skrev Small Shop Concepts:
> > > That can be accomplished in the post processor of most cam
> > > softwares,
> > > it
> > > writes the tool lost at the top of the gcode file.
> > > 
> > > On Fri, Jan 13, 2023, 4:32 PM Nicklas SB Karlsson 
> > > wrote:
> > > 
> > > > Anyone else think it would be useful with possibility to show
> > > > which
> > > > tools a loaded NC file use?
> > > > 
> > > > Then pressing a button list with tools needed is shown. So far
> > > > I
> > > > have
> > > > manually read the g-code file to determine which tools must be
> > > > prepared.
> > > > 
> > > > 
> > > > Nicklas Karlsson
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > 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
> 
> ___
> 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] Ran into a intermittent problem with Jog stop.

[Nicklas SB Karlsson]

tis 2023-01-17 klockan 19:02 +0100 skrev Hans Unzner:
> 
> Am 17.01.23 um 02:44 schrieb gene heskett:
> > If using a wireless keyboard, check the batteries with a voltmeter.
> > Long
> > keydowns may cause a fadeout that does not register as a keyup
> > event. 
> > So when it comes time to send the keyup, the batteries are too low.
> > Any battery that's below 1.4 volts probably need to see if you can
> > hit 
> > the trash can with it from where ever you are.  The one time that
> > hit 
> > me, taught me to use the mdi.
> Correct me if I am wrong, but this is about clicking the buttons on
> the 
> GUI and not using the keyboard buttons.
> The unreliable behavior of using the keyboard to jog is well-known.
Then using keyboard. Press esc and machine stop but sticky behavior
persist if key is pressed again.

Have tried G90 before but I now also try jogging using GUI and then
sticky behavior on keyboard disappear.

It does not happen every time. This time g-code was stopped in the
middle of program because I made an error in g-code mill drilled
instead of ramping.


Nicklas Karlsson



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

Re: [Emc-developers] Ran into a intermittent problem with Jog stop.

[Nicklas SB Karlsson]

tis 2023-01-17 klockan 19:02 +0100 skrev Hans Unzner:
> 
> Am 17.01.23 um 02:44 schrieb gene heskett:
> > If using a wireless keyboard, check the batteries with a voltmeter.
> > Long
> > keydowns may cause a fadeout that does not register as a keyup
> > event. 
> > So when it comes time to send the keyup, the batteries are too low.
> > Any battery that's below 1.4 volts probably need to see if you can
> > hit 
> > the trash can with it from where ever you are.  The one time that
> > hit 
> > me, taught me to use the mdi.
> Correct me if I am wrong, but this is about clicking the buttons on
> the 
> GUI and not using the keyboard buttons.
> The unreliable behavior of using the keyboard to jog is well-known.
It is then using keyboard. Have not tried what happen if GUI buttons
are used then it happen.

A little bit odd it disappear issuing a G90 command.



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

Re: [Emc-developers] Ran into a intermittent problem with Jog stop.

[Nicklas SB Karlsson]

mån 2023-01-16 klockan 16:14 -0900 skrev Johannes Fassotte:
> I'm using master that I down loaded about  10 days ago with Gmoccapy 
> that came with it. I was controlling my mill just using the jog
> buttons 
> and chose not to send commands using MDI mode. This machining work 
> required the jog button to be pushed for minutes at a time and then 
> released when the desired axis travel was completed.
> 
> On a number of occasions I had to push the machines emergency stop 
> button to stop the jog since releasing the jog button did absolutely 
> nothing. ...

Have had similar problems.

Just short movements and pressing key it change direction but do not
stop then button is released. Ordinary USB keyboard with real cable. If
a G90 command is issued this sticky behavior disappear.

It is known to happen sometimes after probe tool length but now always.


Nicklas Karlsson



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

Re: [Emc-developers] Show used tools for loaded NC program?

[Nicklas SB Karlsson]

Marked lines are comments, they are not executed and they do not follow
a formal syntax.

T6 M6 do a tool change so this tool is certainly used in g-code.

Nicklas Karlsson


fre 2023-01-13 klockan 19:38 -0500 skrev Small Shop Concepts:
> here is an example of the tool list in the gcode file:
> 
> [image: tool_list.png]
> 
> 
> On Fri, Jan 13, 2023 at 6:23 PM Nicklas SB Karlsson 
> wrote:
> 
> > fre 2023-01-13 klockan 22:16 + skrev andy pugh:
> > > On Fri, 13 Jan 2023 at 21:32, Nicklas SB Karlsson 
> > > wrote:
> > > > 
> > > > Anyone else think it would be useful with possibility to show
> > > > which
> > > > tools a loaded NC file use?
> > > 
> > > The Axis interface has G-code properties that show the file
> > > extents,
> > > distance etc. It feels like it ought to be possible to track the
> > > tools
> > > used whilst capturing that data.
> > > 
> > Yes to show the tools used in this dialog might be the right place.
> > 
> > 
> > Nicklas Karlsson
> > 
> > 
> > 
> > ___
> > 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] Show used tools for loaded NC program?

[Nicklas SB Karlsson]

fre 2023-01-13 klockan 22:16 + skrev andy pugh:
> On Fri, 13 Jan 2023 at 21:32, Nicklas SB Karlsson  wrote:
> > 
> > Anyone else think it would be useful with possibility to show which
> > tools a loaded NC file use?
> 
> The Axis interface has G-code properties that show the file extents,
> distance etc. It feels like it ought to be possible to track the
> tools
> used whilst capturing that data.
> 
Yes to show the tools used in this dialog might be the right place.


Nicklas Karlsson



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

Re: [Emc-developers] Show used tools for loaded NC program?

[Nicklas SB Karlsson]

Looking into file generated by post processor I used it does not print
a list of tools used.

It is easy to miss one and then program in best case quit then row to
insert tool is reached, not a big problem but still annoying. In best
case it would also check if tool is in tool table, this check should
work if each tool get a unique number.

Nicklas Karlsson


fre 2023-01-13 klockan 16:39 -0500 skrev Small Shop Concepts:
> That can be accomplished in the post processor of most cam softwares,
> it
> writes the tool lost at the top of the gcode file.
> 
> On Fri, Jan 13, 2023, 4:32 PM Nicklas SB Karlsson  wrote:
> 
> > Anyone else think it would be useful with possibility to show which
> > tools a loaded NC file use?
> > 
> > Then pressing a button list with tools needed is shown. So far I
> > have
> > manually read the g-code file to determine which tools must be
> > prepared.
> > 
> > 
> > Nicklas Karlsson
> > 
> > 
> > 
> > ___
> > 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] Show used tools for loaded NC program?

[Nicklas SB Karlsson]

Anyone else think it would be useful with possibility to show which
tools a loaded NC file use?

Then pressing a button list with tools needed is shown. So far I have
manually read the g-code file to determine which tools must be
prepared.


Nicklas Karlsson



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

Re: [Emc-developers] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

ons 2022-12-21 klockan 19:59 + skrev andy pugh:
> On Wed, 21 Dec 2022 at 19:54, Nicklas SB Karlsson  wrote:
> 
> > Specify three points in 2D or 3D space: start, centre and end
> > points as
> > you suggest I think is a good idea that will work for an arc.
> 
> That defines two possible arcs (simplistically, the short one and the
> long one)
> 
> > If I think correct it should be possible to program a foam cutter
> > the
> > same way as a 5-axis mill. A point on the wire is assumed to be the
> > "tool tip" while kinematics solve the rest of the problem.
> 
> It could be done, but the precision with which the A and B angles
> would need to be specified would require a lot of places of decimals.
> 
Another option if not already mentioned before or in a link is to use a
vector from the tool position instead of angles to define tool angle.

Then three coordinates in the space could be used to define an arc for
the tool direction from tool position. While three coordinates is used
to define path for tool position. Both arcs reach the end point at same
time. Expect it should work for both foam cutter and 5-axis mill.


Nicklas Karlsson



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

Re: [Emc-developers] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

ons 2022-12-21 klockan 19:59 + skrev andy pugh:
> On Wed, 21 Dec 2022 at 19:54, Nicklas SB Karlsson  wrote:
> 
> > Specify three points in 2D or 3D space: start, centre and end
> > points as
> > you suggest I think is a good idea that will work for an arc.
> 
> That defines two possible arcs (simplistically, the short one and the
> long one)
> 
> > If I think correct it should be possible to program a foam cutter
> > the
> > same way as a 5-axis mill. A point on the wire is assumed to be the
> > "tool tip" while kinematics solve the rest of the problem.
> 
> It could be done, but the precision with which the A and B angles
> would need to be specified would require a lot of places of decimals.
> 
A floating point number have the same number significant digits
wherever the decimal point is put so maybe not a big problem.

Then it should be one arc on top and anouther one on bottom?



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

Re: [Emc-developers] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

ons 2022-12-21 klockan 13:23 + skrev andy pugh:
> On Wed, 21 Dec 2022 at 12:12, Stuart Stevenson 
> wrote:
> > 
> > A point and a vector fully describe a plane in 3D space.
> 
> Indeed, and you could certainly have a command to set a generic
> plane.
> But you don't need the point. G17 and friends do not define a plane,
> they define a continuum of planes (for example G17 is all XY planes
> for every possible Z)
> 
> There are two discussions here that are getting mixed up. (and
> neither
> correspond to the subject any more)
> 
> 1) Arbitrary arcs. There are a few ways to do this. You could
> certainly define an arbitrary plane then run the arc. With a normal
> vector defined the G2/G3 direction is well defined. But you could
> also
> specify start, end and centre (in 3D space) on one G-code line which
> also fully describes two possible arcs. Or (start) end and waypoint,
> using (XYZUVW) and (IJK) which unambiguously defines a single arc.

Specify three points in 2D or 3D space: start, centre and end points as
you suggest I think is a good idea that will work for an arc. However
not totally sure specify centre point should be totally disregarded.

If I think correct path should be the same in the three dimensions XYZ
if arc is in XYZ space only or if tool direction UVW also change. For a
foam cutter I expect "tool tip" is decided to be on a certain point on
the wire while UV change direction. If foam cutter is wire between two
axis moving in XY direction I suggest kinetamics have to resolve it
into XYUV to make programming same as 5-axis mill, however not sure
which coordinate system is used for programming a 5-axis mill.

Expect arc work also for example for only XY coordinates if nothing
more is needed. Left out axis is assumed constant at current position.

Arc will be circle for one turn instead of a spriral but if I think
correct spiral could be programmed with several half circles. Not sure
adding an extra spiral option is good or confusing.

> Defining an arbitrary plane would mean that spiral arcs remain
> possible, but there is quite a lot of maths in defining it. End
> points
> and waypoint can be pulled off of a CAD model.
> There is an old "arbitrary arcs" branch,
> https://github.com/LinuxCNC/linuxcnc/tree/arbitrary-arc that uses
> magic comments to define the arc. But I think this was just a proof
> of
> concept and the plan wouldn't have been to keep that method.
> 
> 2) Simultaneous curves (arcs, NURBS) for foam cutters. This would
> need
> a way to either define two end points and two centres on one G-code
> line, or a way to "cache" end points and centre on the line before
> (which would be unusual but not entirely outside the G-code
> paradigms).
> Maybe PQR for UVW centre? PQ would certainly be possible for UV arcs,
> re-using R would be a bit unusual for UW and VW arcs.
> This wouldn't work for NURBS, though, which already uses P. But
> perhaps Q could be used for the "secondary" plane in that case.
> Consistency is a problem.

If I think correct it should be possible to program a foam cutter the
same way as a 5-axis mill. A point on the wire is assumed to be the
"tool tip" while kinematics solve the rest of the problem.

Nicklas Karlsson



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

Re: [Emc-developers] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

ons 2022-12-21 klockan 06:08 -0600 skrev Stuart Stevenson:
> A point and a vector fully describe a plane in 3D space.
Yes there that's another option.

If three points are given to define an arc in a three dimensional space
it will be in a "flat" plane.

> 
> On Wed, Dec 21, 2022 at 2:40 AM Nicklas SB Karlsson 
> wrote:
> 
> > ons 2022-12-21 klockan 00:47 + skrev andy pugh:
> > > On Tue, 20 Dec 2022 at 21:27, Nicklas SB Karlsson 
> > > wrote:
> > > 
> > > > Three points with three in the (x,y,z) space will define an arc
> > > > in
> > > > three dimensions. Then there is three degrees of freedom for
> > > > the
> > > > tool
> > > > direction at each point or two for a rotating/"round" tool if I
> > > > think
> > > > correct.
> > > 
> > > We have been discussing this on the forum (At least, I think it
> > > was
> > > there) and someone had the idea of defining both an end point and
> > > a
> > > point part-way along the arc. This gives an unambiguous arc in
> > > three
> > > dimensions. If you define the centre point (in three dimensions)
> > > then
> > > with a start and an end you get two options. And you can't easily
> > > define a clockwise and anticlockwise for an arbitrary plane...
> > Maybe. Give three points then centre point need to be calculated by
> > Linuxcnc but if this does not have accuracy problem for the path I
> > guess it is  a good option.
> > 
> > 
> > > But this isn't what I was rambling about, I was discussing making
> > > arcs
> > > in XY and UV _simultaneously_ where the arcs have different radii
> > > and
> > > centre points.
> > > The issue is not one of maths, but of G-code letters to use for
> > > the
> > > parameters.
> > > An option might be a G2.1 and G3.1 to "queue up" an arc, to be
> > > run
> > > concurrently with the next feed move.
> > Give all four coordinates (X,Y,U,V) at start point, middle point
> > and
> > end point?
> > 
> > Then arc for path could be calculated from (X,Y) coordinates and
> > arc
> > for cutting direction by (U,V) with same mathematics will do the
> > trick?
> > Or thinking wrong a four dimensional arc need to be calculated?
> > 
> > 
> > Nicklas Karlsson
> > 
> > 
> > 
> > ___
> > 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] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

ons 2022-12-21 klockan 00:47 + skrev andy pugh:
> On Tue, 20 Dec 2022 at 21:27, Nicklas SB Karlsson  wrote:
> 
> > Three points with three in the (x,y,z) space will define an arc in
> > three dimensions. Then there is three degrees of freedom for the
> > tool
> > direction at each point or two for a rotating/"round" tool if I
> > think
> > correct.
> 
> We have been discussing this on the forum (At least, I think it was
> there) and someone had the idea of defining both an end point and a
> point part-way along the arc. This gives an unambiguous arc in three
> dimensions. If you define the centre point (in three dimensions) then
> with a start and an end you get two options. And you can't easily
> define a clockwise and anticlockwise for an arbitrary plane...
Maybe. Give three points then centre point need to be calculated by
Linuxcnc but if this does not have accuracy problem for the path I
guess it is  a good option.


> But this isn't what I was rambling about, I was discussing making
> arcs
> in XY and UV _simultaneously_ where the arcs have different radii and
> centre points.
> The issue is not one of maths, but of G-code letters to use for the
> parameters.
> An option might be a G2.1 and G3.1 to "queue up" an arc, to be run
> concurrently with the next feed move.
Give all four coordinates (X,Y,U,V) at start point, middle point and
end point?

Then arc for path could be calculated from (X,Y) coordinates and arc
for cutting direction by (U,V) with same mathematics will do the trick?
Or thinking wrong a four dimensional arc need to be calculated?


Nicklas Karlsson



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

Re: [Emc-developers] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

mån 2022-12-19 klockan 13:04 + skrev andy pugh:
> On Mon, 19 Dec 2022 at 11:27,  wrote:
> 
> > I do not know what seicanon.cc is for!
> 
> saicanon is related to the "stand alone interpreter" which I think
> is,
> in turn, related to the G-code preview and (maybe) some of the tests.
> https://linuxcnc.org/docs/stable/html/code/rs274.html
> (The manpage above tells you very little)
> 
> > So first arc() has to be expanded to UVW planes?
> 
> Ideally, yes. Though it isn't clear how you would do that if you were
> also trying to cut an arc at the other end of a foam cutter in the XY
> plane.
> 
> The issue with arcs is that it isn't clear how to define the centre
> point for UVW arcs.
> 
> This is moving well away from your original pull request, so don't
> consider the following to be a wish-list for that. But I think it is
> an interesting point of discussion.
> 
> For foam cutters it would be really nice to be able to cut
> simultaneous arcs and NURBS / Splines on each end of the machine. But
> it is difficult for a number of reasons:
> 1) How do you define the arc centres for UVW arcs? (especially if you
> are _simultaneously_ doing an XYZ arc.)
Three points with three in the (x,y,z) space will define an arc in
three dimensions. Then there is three degrees of freedom for the tool
direction at each point or two for a rotating/"round" tool if I think
correct.

> 2) Synchronisation: Arcs are not too hard, each end of the wire gets
> to the end of the arc at the same time. It's not so clear with
> NURBS/Splines. Do you aim to hit control points simultaneously? Or
> finish the entire curve simultaneously?
> 3) Plane definition. Currently we have G17,18,19,17.1,18.1,19.1.
>   
> https://linuxcnc.org/docs/stable/html/gcode/g-code.html#gcode:g17-g19.1
>     We would need to find a way to define "simultaneous planes" or
> possibly just allow UV arcs if the XY plane is selected (and run them
> simultaneously). (possibly it makes sense for compatibility to make
> this the default G17.1 mode, as this doesn't alter anything that
> currently works)

Should be possible to define a "flat" plane in a three dimensional
space with three vectors.


Nicklas Karlsson



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

Re: [Emc-developers] Mesa error finishing read errors solved --> Ethercat message disappear

[Nicklas SB Karlsson]

ons 2022-12-14 klockan 05:15 +1000 skrev Rod Webster:
> Since the 5.10 kernel (eg Bullseye) and above, there has been an
> issue with
> excessive network latency with the Debian RT kernel and Realtek
> network
> interfaces with Mesa ethernet cards. When it bites, it causes a
> hm2_eth
> "error finishing read" and disables the mesa card.  By avoiding
> realtek
> NIC's a whole swathe of small portable industrial PC's can no longer
> be
> used with linuxcnc. A resolution for this issue needs to be found
> before
> 2.9 rolls out or there will be massive support issues.
> 

> This issue is restricted to the debian environment. Installing a
> compiled
> kernel or running on a non-debian distribution solves the issue (I
> tried
> arch-linux)
> 
> By default Debian uses the r8169 network driver for all realtek NIC's
> but
> provides a r8168-dkms driver which should solve the issue if
> installed if
> supported hardware is present. However,  it appears that when this is
> installed, the network latency is rarely resolved. I suspect it is
> because
> of a buggy driver in Debian. Some people (PCW, JT et al) have
> resorted to
> compiling the kernel from pristine sources.
> 
> I have finally been able to compile a 6.1 version of the PREEMPT_RT
> kernel
> and headers which I have stored in Google Drive

Have had problem with ethercat message disappear then more than a few
cards are connected in series. Using lsmod I could see mdio_devres
r8169 so maybe this also explain the problem with Ethercat.

Have however not yet checked.

Nicklas Karlsson



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

Re: [Emc-developers] Arc Bug, help needed.

[Nicklas SB Karlsson]

lör 2022-12-10 klockan 23:10 + skrev Dewey Garrett:
> 
> > Is anyone else able to reproduce this behaviour?
> 
> $ wget www.panix.com/~dgarrett/stuff/arc.tgz
> $ tar xzf arc.tgz
> $ cd arc
> 
> 1) start from command line
> $ linuxcnc arc.ini
> 
> 2) Initialize
> F1 -- Machine on
> F2 -- Estop off
> Ctrl-HOME --- Home all
> # Display shows one turn spiral
> 
> 3) Examine residual settings after homing:
> (too small to be visible on display)
> # example:
> $ halcmd show pin axis.[xyz].pos-cmd
> Component Pins:
> Owner   Type  Dir Value  Name
>     23  float OUT  2.569163e-08  axis.x.pos-cmd
>     23  float OUT  2.845021e-09  axis.y.pos-cmd
>     23  float OUT  2.569163e-08  axis.z.pos-cmd
> 
> 4) r - Run program
> #  observe errant linear (z) move, no spiral
> 
> 5) r - Run program
> # observe correct execution of circle at z=-1
There is an issue if end point for a circle is exaxtly at one turn.
Adding a nanometer to not make it slightly more or less solve the
problem?



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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Nicklas SB Karlsson]

Read that DDS include application programming interfaces (APIs) and
libraries of implementations in among others ADA and that's great.


tis 2022-12-06 klockan 13:55 -0600 skrev Bari:
> On 12/5/22 15:21, Johannes P Fassotte wrote:
> 
> > 
> > On 12/5/2022 6:10 AM, Bari wrote:
> > > A pdf that explains where DDS fits in to industry 
> > > https://www.dds-foundation.org/sites/default/files/RTILunchAddressOMG2014v2.pdf
> > > 
> > > If we use DDS it might make LCNC compatible with the industry of
> > > the 
> > > future. Is everyone jumping onto the DDS bandwagon? Which
> > > messaging 
> > > system will gives us the best chance at fitting into factory 
> > > automation, CNC machines and robotics of the near future (next 20
> > > years)? Will this best solve the issues of separating the
> > > controls 
> > > from the GUI over the network as well as connect LCNC to factory 
> > > controls and robot material handlers? Is this mission creep or 
> > > killing two birds with one stone?
> > 
> > Bari,
> > 
> > I tend to agree that this is a good solution. In looking at the 
> > openDDS project I see that the project has been forked 408 times on
> > github including my own fork. It also has a good developers guide
> > that 
> > contains some 249 pages of information and also has the required 
> > support package for TOA available which has development guide that
> > has 
> > some 1262 pages. OpenDDS seems like it has good documentation on
> > its 
> > own and thus only requires LinuxCnc documentation to be added on
> > how 
> > to get it to install and get it working  with LinuxCnc.
> > 
> > I think that working on this is much more beneficial to LinuxCnc
> > than 
> > my previous concept which obviously does not have a lot of support
> > so 
> > I may as well forget about working on that. But that does not mean 
> > that the requirement for improved network capability does not
> > exist.
> > 
> > OpenDDS has its own own development team which thus requires less 
> > support from the LinuxCnc development team. All that needs to be
> > done 
> > is to get it working within LinuxCnc. So my intention is to work on
> > helping to accomplishing that. OpenDDS uses CorBa instead of Redis
> > so 
> > Redis will most likely not be required.
> > 
> > My starting point for this project is to get openDDS  working
> > inside 
> > and in parrallel with current LinuxCnc master code, without
> > changing 
> > LinuxCnc  code and to only add the code required to make openDDS 
> > functional within LinuxCnc. Once it is functioning and able to run 
> > simple self tests then  start working on routing individual
> > LinuxCnc 
> > commands along with the status data of those into openDDS and route
> > those to an prior developed Labview based UI running on a Windows10
> > computer. That will be helpful with checking the networking
> > functions 
> > and any debugging work. Labview has some tools that are very handy
> > for 
> > doing that but others joining the project could decide use any UI
> > that 
> > has remote ability for there own testing.
> > 
> > This seems like an excellent project to undertake and I'm somewhat 
> > excited about getting started on this project.  OpenDDS appears to 
> > have good support and is already being used for such purposes. I
> > have 
> > downloaded what I believe to be all required items for installation
> > and will get my Debian development system set up to start doing
> > work 
> > on this before the end of the year.
> > 
> > 
> Sounds great. Let us know when you have a public repo so that we can 
> follow your deep dive into this.
> 
> 
> ___
> 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] A vision for working now to LinuxCnc version 10

[Nicklas SB Karlsson]

lör 2022-12-03 klockan 21:22 +0100 skrev Steffen Möller:
> Hello,
> 
> > My goal for LinuxCnc is to provide a way for any user to interface
> > any
> > UI to LinuxCnc with a secure TCP network connection.
> 
> There are remote shells to HAL but I agree - would also like to see a
> bit more of remote control. My motivation is less about the distance
> than it is about controlling multiple machines from the same host -
> cooperating robots anyone?

Hopefully soon. with robot feeding a machine I guess use same user
interface for both might be convenient.



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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Nicklas SB Karlsson]

lör 2022-12-03 klockan 16:57 -0800 skrev chris morley:
> 
> On 2022-12-03 16:06, Johannes Fassotte wrote:
> > I’m fairly familiar with machine kit and it has nothing to do with
> > that. It has strictly to do with modernizing the built in remote
> > interface that Linuxcnc was born with..
> 
> ok You must realize almost no one uses the networking capability of 
> linuxcnc.

Tried it but id did not get it to work.

> 
> It seems to be the case that most machines have the controls on the 
> machine so over network is not that important. Certainly its a 
> limitation in some cases. I guess I don't see why its 
> the-most-important-thing that you seem to?

Not many years ago it made sense with a real time computer without
displays an ordinary computer for user interface. It make less sense
now since ordinary computer seems to work well as real time computer.

Nicklas Karlsson




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

Re: [Emc-developers] manual tool change

[Nicklas SB Karlsson]

Have implemented a manual tool change component.

To release tool hydraulic pump is started and stopped. To clamp tool
hydraulic pressure have to be released. There is also two digital
inputs from sensors that will tell if open or closed.

There is buttons to unlock tool, clamp tool and tell then done
otherwise machine woule start immediately then clamped.


Nicklas Karlsson



tor 2022-12-01 klockan 10:37 -0600 skrev Jon Elson:
> On 11/21/22 19:35, Jon Elson wrote:
> 
> I have a user who tried to implement the manual tool change 
> button in LinuxCNC 2.8, he says there is no continue button 
> displayed.
> His original code was :
> 
> loadusr-W hal_manualtoolchange
> 
> net tool-change iocontrol.0.tool-change => 
> hal_manualtoolchange.change
> 
> net tool-changed iocontrol.0.tool-changed <= 
> hal_manuatoolchange.changed
> 
> net tool-number iocontrol.0.tool-prep-number => 
> hal_manualtoolchange.number
> 
> net tool-prepare-loopback iocontrol.0.tool-prepare => 
> iocontrol.0.toolprepared
> 
> net tool-changed-btn hal_manualtoolchange.change_button <= 
> parport.0.pin-15-in
> 
> This would not start, as there was no parport in his 
> system.  I told him to just delete the last line, I assumed 
> this would just use the on-screen  button to continue from 
> the tool change.  But, now he doesn't get a "continue" 
> button on the screen.  Does the new version require a 
> hardware button, or require a signal to be netted to the 
> hal_manualtoolchange.change_button?
> 
> Thanks for any insight, I don't use this feature at the moment.
> 
> 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

Re: [Emc-developers] LinuxCnc growing with to much none essential code

[Nicklas SB Karlsson]

> ...
> As far as tools for building user interfaces It would also not
> surprise 
> me if the next fad for building those is just around the corner and
> that 
> QT will hopefully be just part of the old LinuxCnc history.  I there 
> will always be newer and better ways to get things done without
> getting 
> trapped into a current fad.
Used glade for adding extra panel and think it works rather well.
> ...



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

Re: [Emc-developers] G96 Constant surface speed, have to move some distance before active

[Nicklas SB Karlsson]

mån 2022-11-14 klockan 00:06 + skrev andy pugh:
> Just to clarify: Is this still an issue, or was it a misunderstanding
> of CSS mode?
> 
Maybe a little bit of a misunderstanding as it was intended for lathes.
Though for mills it make it either work considering the drill diameter
instead of the x position or G96 is disabled give an error message if
used.

Nicklas Karlsson



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

Re: [Emc-developers] Next LinuxCNC online meeting

[Nicklas SB Karlsson]

sön 2022-10-23 klockan 20:17 +0200 skrev Hans Unzner:
> Hi!
> 
> The last online meeting was in august, so time for a follow-up.
> 
> In short we would like to speak about:
> 
>   * The upcoming 2.0 release
>   * Transfer of features from MachineKit
>   * Documentation: Style guide, po4a migration status, migration to
>     Asciidoctor
>   * Collaboration with industry on tool table format
> 
> For a more detailed agenda, see 
> https://docs.google.com/document/d/1aWMxBY8IbCYXFLFvjgqUXZ09inZp5u0r-pZcjeb2bWk/
Reading the agenda. FreeCAD I just added a small experimental zig cut
pattern for facing operation. Path workbench is not perfect but used it
and successfully used the g-code from post processor to machine a few
small part.

Expect CAM module in CAD program is the preferred method to get g-code
program.


Nicklas Karlsson



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

Re: [Emc-developers] LinuxCNC + LXRT (RTAI) results

[Nicklas SB Karlsson]

Just to confirm, picture received.

sön 2022-10-09 klockan 04:32 + skrev Alec Ari via Emc-developers:
> Note: Using LXRT realtime
> 
> Pic attached (not sure if mailing list accepts pictures, CC'ing to
> Bari to post on forums if necessary)
> 
> Alec
> ___
> 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] G96 Constant surface speed, have to move some distance before active

[Nicklas SB Karlsson]

Den 2022-09-20 kl. 11:27, skrev Jérémie Tarot:

Le mar. 20 sept. 2022 à 02:41, Feral Engineer 
a écrit :


Trust me, I'm well aware of what css is. 


I bet you do ! 
That was actually me thinking out loud, and I should have put a question
mark because I still don't get how CSS could work for milling 樂


Pretty easy calculate rotational speed from given surface speed and tool 
diameter. It could be done the "normal" way using G97 entering 
rotational speed or with G96 let Linuxcnc do the calculation entering 
the surface speed.


Thinking about a lathe and testing again rotational speed of course 
depend X position. Should most certainly make no sense to change 
rotational speed depending on X position on a mill and if not based on 
the tool diameter better disable it.


Nicklas Karlsson




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

Re: [Emc-developers] G96 Constant surface speed, have to move some distance before active

[Nicklas SB Karlsson]

Den 2022-09-18 kl. 21:20, skrev Jérémie Tarot:

Le jeu. 15 sept. 2022 à 12:25, Nicklas SB Karlsson  a écrit :.


Is there any good reason surface speed should start at maximum until
tool is moved? Or would it be better tool does not have be moved before
surface speed is active?



What's the X position of the tool after tool change and the active
work/rapid mode?

Shouldn't G96 be enabled only just before lead in move?


Maybe on lathe.

Use it on a mill. If diameter of drill is changed rpm will change so 
that surface speed is the same and guess feed normally make very little 
or negligible difference. Tables I have surface speed is the same for 
different diameters so it make sense even though not very important 
though with well written g-code program it is possible to change 
diameter of a tool and part is still correctly machined.



Nicklas Karlson



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

[Emc-developers] G96 Constant surface speed, have to move some distance before active

[Nicklas SB Karlsson]

Change tool and use constant surface speed G96 with proper parameters. 
Then spindle is started without moving it run at maximum speed 
regardless of which surface speed S have been set. Moving some distance, 
guess it might depend on tool diameter or radius then S parameter start 
to work.


Is there any good reason surface speed should start at maximum until 
tool is moved? Or would it be better tool does not have be moved before 
surface speed is active?



Nicklas Karlsson



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

Re: [Emc-developers] NURBS in XY, XZ(lathe) and YZ plane

[Nicklas SB Karlsson]

Do not feel there is a need for more gun barrels or increased accuracy 
in world, there are already more than needed in the world.


Den 2022-08-14 kl. 18:24, skrev gene heskett:

On 8/14/22 08:04, andy pugh wrote:

On Sun, 14 Aug 2022 at 09:56,  wrote:

Hello,

it is worth to spend my time to do this?
I looked to the code and it seems doable.

I think that it is a pity that it only works in XY. However I have
never used the feature and don't know how often it is used. I don't
believe that any CAM packages know how to use it.


Why not go all the way, to the 9 currently defined?

As for usefulness, the first place I might try it would in be 
profiling a rifle barrel,
perhaps with some math help from a finite analysis of some sort. 
Firing a round
obviously generates a vibration, a whipping of the barrel, the 
magnitude of which
affects the accuracy. If the bullet exits the barrel in the center of 
this vibration,
it is moving at maximum velocity whichever way the barrel is 
vibrating. You can
quickly change a 1" at 100 yards gun into a 5 incher that might 
completely

miss the venison you were trying to harvest.

By changing the profile of the barrel, or the mass on the end of it as 
Browning has
been doing for around 20 years now, you can tune this vibration in 
such a way as to
put the bullet leaving the end of the barrel at the maximum amplitude 
of this
vibration, which corresponds to the minimum horizontal speed. By 
tuning this
to hit that minimum speed point for your favorite load, that elusive 
10 shots
into one ragged hole can be achieved. The smaller that hole is, the 
higher you
are ranked on the wailing wall at the national shoots, And at some 
shoots it

can have a very large effect on the size of the paycheck.

It also sells barrels. I put a fresh barrel on old AT 3 years ago, and
haven't look back. Made by the same maker that won quite a few of 
those shoots.
With my aged eyes, that 6.5mm Creedmoor is giving me one MOA targets, 
reliably.

That is good enough for the girls I go with.

Unfortunately the rules for those shoots eliminate me as that one 
weighs in about
10 lbs too heavy.  They intend to make you compete with hunting weight 
rifles.

If you were going to do this, then I feel that adding UV would also be
useful. There is a sub-set of users that use XY/UV hot wire cutters to
make airfoils who might, possibly, want to use Nurbs.
(Though, actually, they probably use the NACA equations?
https://en.wikipedia.org/wiki/NACA_airfoil )




Cheers, Gene Heskett.



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

Re: [Emc-developers] Axis motion in user M-code?

[Nicklas SB Karlsson]

Den 2022-07-31 kl. 13:45, skrev andy pugh:

Is there a way to move axes in the M100-M199 codes?


Have also been thinking about. If I got it right .comp is converted to 
C/C++ code so the question is possibility to do it from there. Python 
are some kind of wrapper executing C/C++ code?



Nicklas Karlsson




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

Re: [Emc-developers] custom homing comp for meca500 ethercat robot (Product running)

[Nicklas SB Karlsson]

Den 2022-08-06 kl. 15:29, skrev gene heskett:

On 8/6/22 08:34, Nicklas SB Karlsson wrote:
Spent maybe a full minute or two looking into manual for the 
mecademic robot. If robot have builtin position controller adding a 
second one on top in Linuxcnc is most certainly no good idea.



Driver cards I am developing is useful on old machine with non 
working electronics. Guess it is hopeless co compete with large 
companies on new products manufactured in large series.


Maybe Nicklas, but one way to assure that is to "keep your candle 
under a bushel."
So how about a link to the product, and let the market decide if it is 
a better way.


Here one of the first tries maybe two years ago 
https://www.youtube.com/watch?v=EUmGY5cM718 air cooling running slow 
unsure about feed and rotational speed.



Nicklas Karlsson



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

Re: [Emc-developers] custom homing comp for meca500 ethercat robot

[Nicklas SB Karlsson]

Spent maybe a full minute or two looking into manual for the mecademic 
robot. If robot have builtin position controller adding a second one on 
top in Linuxcnc is most certainly no good idea.



Driver cards I am developing is useful on old machine with non working 
electronics. Guess it is hopeless co compete with large companies on new 
products manufactured in large series.



Nicklas Karlsson


Den 2022-08-02 kl. 17:15, skrev David (J) Smith:

Hi!

I have tried running the auto PID module - at_pid

However after work the joints seem to continually bounce and wobble 1 or two 
degrees with the resulting settings from

setp pid.j0.tune-effort 0.1
setp pid.j0.tune-mode 1
setp pid.j0.tune-type 0
setp pid.j0.tune-start 1

https://github.com/djsftree/linuxcnc_meca500/tree/main/linuxcnc/configs/min-meca500

Is there anyone available to briefly review my  ini file ?

Best regards,

David Smith



-Original Message-
From: David (J) Smith 
Sent: 29 July 2022 16:27
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] custom homing comp for meca500 ethercat robot

Hi!

I’m working on an internal project involving the Mecademic Meca500 6 axis robot 
https://www.mecademic.com/en/meca500-robot-arm

Is there anyone on the mailing list that is available for linuxcnc development 
/ contract work?

Here’s some useful links so far

Cyclic data that can be sent to the robot
https://cdn.mecademic.com/uploads/docs/meca500-r3-programming-manual-8-4.pdf#subsection.3.4

Cyclic data received from the robot
https://cdn.mecademic.com/uploads/docs/meca500-r3-programming-manual-8-4.pdf#subsection.3.5

Communicating over ethercat
https://cdn.mecademic.com/uploads/docs/meca500-r3-programming-manual-8-4.pdf#section.4

ethercat XML file
https://github.com/djsftree/linuxcnc_meca500/blob/main/linuxcnc/configs/meca500/meca500-ethercat.xml

custom homing comp skeleton
https://github.com/djsftree/linuxcnc_meca500/blob/main/linuxcnc/configs/meca500/meca500_homing.comp

I would welcome a review of the initial skeleton code and any suggestions to 
the potential homing architecture.

The robot has its own internal mechanism for homing once the robot is activated.

-- set
ctrl.activate 1
ctrl.deactivate 0

-- wait for
status.activated 1
status.busy 0

-- set
ctrl.home 1

j0, j1, j2 rotate 3.6deg
j3, j4 rotate 7.2deg
j5 rotates 12deg
this procedures takes 3 seconds to complete
joint position during homing is available on ethercat encoder.a1 thru a6

-- wait for
status.homed 1
status.busy 0

-- homed and ready to accept motion commands


Best regards,

David Smith


___
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] custom homing comp for meca500 ethercat robot

[Nicklas SB Karlsson]

Den 2022-08-02 kl. 17:15, skrev David (J) Smith:

Hi!

I have tried running the auto PID module - at_pid

However after work the joints seem to continually bounce and wobble 1 or two 
degrees with the resulting settings from

setp pid.j0.tune-effort 0.1
setp pid.j0.tune-mode 1
setp pid.j0.tune-type 0
setp pid.j0.tune-start 1

https://github.com/djsftree/linuxcnc_meca500/tree/main/linuxcnc/configs/min-meca500

Is there anyone available to briefly review my  ini file ?


ini file is probably fine. Small problems like this is common then 
working with feedback.



Nicklas Karlsson



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

Re: [Emc-developers] Addition Ethercat Homing Routine/Variable

[Nicklas SB Karlsson]

fre 2022-07-29 klockan 19:40 +1000 skrev Rod Webster:
> You can create those three pins (start homing, completed, error)  in
> custom_makepins() and connect them to pins created in the ethercat
> xml
> config for your drives.
> They will appear as joint.n.start-homing etc.

I was thinking about the end connected to linuxcnc there the pins
(start homing, completed, error) is needed while in other end whatever
is needed may be created in custom component. Or how do you make the
custom homing component do homing then ordinary home button is pressed
and get feedback then done?


Nicklas Karlsson



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

Re: [Emc-developers] [Hosted Weblate] New comment inLinuxCNC/LinuxCNC Documentation (OT)

[Nicklas SB Karlsson]

> ... "start from line" was added several years ago.  The motion code
> may 
> not be
> re-executed, but the mode changes it implies are.

"start from line" may be used if tool bit break or other problem occur
to start machining at a particular point in program?


Nicklas Karlsson



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

Re: [Emc-developers] Addition Ethercat Homing Routine/Variable

[Nicklas SB Karlsson]

tor 2022-07-28 klockan 21:20 +1000 skrev Rod Webster:
> Nicklas,
> this will be a pretty big brain dump so please read on.
> 
> This is where Dewey's work comes in to solve your problem. You can
> now
> write a custom homing component and install it using halcompile.
> You need to start by reading the homecomp docs
> http://linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html
> Then refer to the sample code
>  
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/homecomp.comp
> You also become familiar with homing.c
>  
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.c
> Homing starts in homing_init()
>  
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.c#L1411
> You might also like to review Dominic Braun's cia402 component
> https://github.com/dbraun1981/hal-cia402 for CANOpen/CIA402 related
> stuff.
> 
> homing_init() in homing.c has been reworked so the default code is
> moved to
> base_homing_init()
> This allows a custom version of homecomp to totally rewrite the
> homing code
> in homing_init and other procedures who have base versions in
> homing.c
> So a custom homing module for CANopen devices might live in a file
> called
> canopen_home.comp and contain its own version of homing_init() that
> starts
> the homing process and just waits until the drive signals homing is
> completed, then set the joint.N.homed pin to true.

In motion module. A pin to start homing and signal completed is OK but
there also ought to be a need to signal an error occured.

Normally then homed motion pins are connected to device. It is possible
to work around with multiplexers but might be useful if these pins are
instead connected to home component then home input pin is true.

> 
> Dominc has some useful stuff in his component and triggered homing
> using joint.N.index-enable
> But Daniel and I found this was not enough, changes to homing.c was
> required. Then Dewey released his custom homing module we are
> discussing
> here.
> Dominic's code has two functions read_all() and write_all() to
> transfer
> data to and from ethercat slaves.
> I think this could be quite a useful technique. I think this could be
> replicated in canopen_home.comp by extending
> void read_homing_in_pins() and write_homing_out_pins() and creating
> any
> additional CANopen pins at the joint level.

Additional CANopen pins at joint level should not be needed in linuxcnc
but may of course be useful in home component at least to show status.

> I did attempt this and got close as I could init the homing process
> but
> cancelling it did not restore the correct state and I did not proceed
> due
> to time constraints.
> I will say working in a homecomp becomes quite complex because you
> have to
> deal with all joints at once so additional data (and pins) must be
> stored in

Most home components do not need any coordination between joints. If
possible to write custom home component it is however possible to write
a home component with pins for several joints there some kind of
coordination is needed.

There is three pins (start homing, completed, error) to connect custom
home component for each joint should be enough.


Nicklas Karlsson



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

Re: [Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Nicklas SB Karlsson]

tor 2022-07-28 klockan 09:53 + skrev Steffen Möller via Emc-
developers:
> 
> 
> #  Comment added
> 
> [ smoe](https://hosted.weblate.org/user/smoe/ "Steffen Möller"):
> [Hosted
> Weblate](https://hosted.weblate.org) /
> [LinuxCNC](https://hosted.weblate.org/projects/linuxcnc/) / [LinuxCNC
> Documentation](
> https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/) /
> [English](
> https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)
> 
> ## Source string
> 
> 'M0' - pause a running program temporarily. LinuxCNC remains in the
> Auto Mode
> so MDI and other manual actions are not enabled. Pressing the resume
> button
> will restart the program at the following line.
> 
> ## Source string description
> 
> type: Plain text
> 
> ## Comment
> 
> I am unhappy with the term "restart". That would imply that something
> would be
> "re"-executed, which is not the case, and variables are not affected,
> either.
> I would prefer "the execution of that program continues in the
> following
> line."

Agree.



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

Re: [Emc-developers] Addition Ethercat Homing Routine/Variable

[Nicklas SB Karlsson]

tis 2022-05-03 klockan 13:09 +0100 skrev andy pugh:
> On Tue, 21 Sept 2021 at 15:35, Daniel Dempsey 
> wrote:
> 
> > Will try to sort out the rest of homing.c this week and hopefully
> > test on
> > the weekend when the shop is quiet.
> 
> This has been sat in my inbox for months awaiting a reply. In the
> meantime, Dewey has introduced a system whereby LinuxCNC can be
> configured to support a custom homing scheme. Have you seen that
> work?
> 
> Here is a sample homing  component:
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/homecomp.comp
> The docs for that component:
> http://linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html

Some commands are limited then not homed and guess motion module tell
Linuxcnc this. Looking into my .hal file there is however neither an
input to tell motion it should home nor an output connected somewhere
to Linuxcnc GUI then it is homed. Not sure what is part of the motion
module but could see it is named motmod in my .ini file.

Pretty sure there is a problem in motion module as it always do the
homing by itself running the joint(s) setting the offsets. There is a
bit output pin in motion module indicating if homing but no possibility
to tell motion module it is done by externally and not possible tell
motion module homing is done or in an error. There is most certainly
also a need to tell motion module if home offset is added or not by
device itself then homing is completed successfully.


Reading CANopen document homing procedure. At first device have to be
set to special "Homing mode". There i an input bit to tell device start
or continue homing. There is also three status bits, it is in
particularly possible to tell i homing is: in progress, failed or done.
Device also do add an offset internally so should not be done by motion
module and it should also expect offset is added position to position
then homing is completed succesfully. Might be possible to access
position with or without added home offset but are uncertain. Even
though device could do homing by itself I found it work great use the
homing procedure builtin into Linuxcnc. There is however a problem
index pulse on encoder usually is to short to detect by Linuxcnc.


Nicklas Karlsson



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

Re: [Emc-developers] sudo make setuid -> cannot gain I/O privileges

[Nicklas SB Karlsson]

udev rules?

Den 2022-07-24 kl. 05:22, skrev Alec Ari via Emc-developers:

I get the same error on Debian with both iopl and ioperm function tests... Not 
sure how LinuxCNC is working anymore on anything..

Alec


___
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] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Nicklas SB Karlsson]

Den 2022-07-06 kl. 14:07, skrev andy pugh:

On Wed, 6 Jul 2022 at 06:51, Nicklas SB Karlsson  wrote:


To use degree while everyone else use radians might be a problem though
might be easier to work with degree. Then doing calculations radians
often have to be used for a CNC machine an example is calculate surface
speed.

You need Pi to calculate surface speed, but not trigonometry. But to
make that really simple we could mandate that spindle speeds all be
stated in radians per second.

Maybe if others do it but otherwise probably not.


Fanuc - degrees.  (But offers G51 part rotation in deg and G52 in rad)
Duet - radians.
Mach3 - degrees
Fagor - degrees
Mitsubishi - degrees


Four out of five in degree then, only Duet in radians. That's different, 
degree ought to be a a good choice for geometry. Guess there are many 
cases then fit corners accurate is simpler in degrees.



Nicklas Karlsson



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

Re: [Emc-developers] [Hosted Weblate] New comment in LinuxCNC/LinuxCNC Documentation

[Nicklas SB Karlsson]

Den 2022-07-05 kl. 14:22, skrev andy pugh:

On Tue, 5 Jul 2022 at 11:47, Steffen Möller via Emc-developers
 wrote:


degrees. Values returned by unary operations which return angle measures
('ACOS', 'ASIN', and 'ATAN') are also in degrees.
This is unexpected. Radial is the default for these functions about everywhere
else. This should be made more explicit.


To use degree while everyone else use radians might be a problem though 
might be easier to work with degree. Then doing calculations radians 
often have to be used for a CNC machine an example is calculate surface 
speed. Adding a g-code to switch might be a good solution.



I would imagine that most CNC operators will expect degrees. Can you
imagine trying to type in a right-angle in MDI in radians?

G1 @20 ^ 90

is far more practical than

G1 @20 ^ 1.570796327




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

Re: [Emc-developers] curious about the ethernet protocol

[Nicklas SB Karlsson]

> ...
> How come you send the velocity commands and not target positions? Size of
> the positioning data I assume?
> 
> I can see this to be super useful when there is an external encoder - so
> linuxcnc is in full control.
> But what's the benefit with e.g. Servos and Closed Loop Stepper that have
> their internal encoder and control loop?

Sending out position instead of velocity also work. Use encoder sending 
position using external feed back loop for position, following error and 
display also work as usual.

> ...
> (Another crazy(?) thought I had was to have an acceleration sensor as
> incoming feedback. To help with servo parameterization.)

Should help at least then there is elasticity in between motor and position 
feed back.

> ...
> It feels like sending the velocity commands over ethernet also means some
> kind of buffering, but I guess the 1kHz feedback loop is the big difference
> here.

NML is for the non real time stuff so no 1kHz feedback loop there.


Nicklas SB Karlsson


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

Re: [Emc-developers] curious about the ethernet protocol

[Nicklas SB Karlsson]

On Sat, 16 Apr 2022 14:15:56 +0200
Torsten Curdt via Emc-developers  wrote:

> > Manual on page 3 http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf
> 
> 
> Thanks for that link. I somehow missed those docs.
> 
> 
> > NML should work over TCP/IP networks including Ethernet but think it is
> > currently out of order and only work using shared memory buffers.
> 
> 
> What's NML?

NML is some kind of communication protocol used internally in Linuxcnc, 
supposed also to work over ordinary TCP/IP network. It may make sense to 
separate user interface from real time computer but with good real time 
performance in an ordinary computer it is not very important, the RT kernel 
have been available for som years but not vary many.


Nicklas Karlsson


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

Re: [Emc-developers] curious about the ethernet protocol

[Nicklas SB Karlsson]

Manual on page 3 http://linuxcnc.org/docs/devel/pdf/LinuxCNC_Developer.pdf

NML should work over TCP/IP networks including Ethernet but think it is 
currently out of order and only work using shared memory buffers. Try to 
get it started using ordinary TCP/IP over ordinary Ethernet network a 
few years ago, might be axis which is the problem.



Ethernet is not well suited for real time control, it is however 
possible in a controlled environment or if some missed dead lines may be 
accepted. There is a difference between video and machine control, 
amount of data is relatively small in machine control but with control 
loop over network it have to be sent very often. Interestingly old ATM 
for telephone network send many small messages, read something about 48 
bytes.


Main problem with Ethernet is then connected to an ordinary network. 
Other messages may arrive at any time and if they are sent first real 
time communication is delayed. Have not yet figured how to tell Linux to 
not send other communication then used as a real time controller though 
probably not very hard, then listening with Wireshark there are coming 
out arp request and other request on the Ethernet port.



Nicklas Karlsson


Den 2022-04-16 kl. 01:23, skrev Torsten Curdt via Emc-developers:

Hey there,

I was wondering the following - and mainly really to understand how
LinuxCNC works.
Since I couldn't get a proper answer in the user chat I thought I would try
here.

IIUC the GCODE interpreter runs in the non-realtime part. It sends the step
instructions to a card to execute the steps. This is obvious when using a
LPT port, but how does this work via Ethernet?

Are the steps compressed into instructions and then applied on the Mesa
cards?
Poking around it seems like there are motion commands and status commands?
So it probably sends "go there" and "where are you" and the card generates
the steps required and reports back. Does that sound right? Is there a
definition of the protocol to look at?
I assume the code of what gets pushed to the Mesa's must be somewhere, too.

And now I hope I don't get lynched for asking:
How is that ethernet protocol different from the Mach3 ethernet protocol?
Are there significant differences between the protocols that would prohibit
LinuxCNC speaking the Mach3 ethernet protocol?

Or maybe no one knows or cares? But I was wondering if
implementing the protocol could be another alternative to flashing Remora
to supported boards.

While waiting for Mesa stocks to recover, I am really just curious to
understand the technical side of the LinuxCNC vs Mach3 comparison.

cheers,
Torsten

___
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 Glade complains about old action widgets

[Nicklas SB Karlsson]

Using glade and gtk it make complain about the VCP actions they are old. 
It is not very important as they still work but does anyone here a good 
idea how to fix them?


I already found there i a list with the widgets in 
lib/python/gladevcp/hal_python.xml and guess something is generated from 
this list. Also found file is mentioned in src/Makefile but have no been 
able to figure where it is accessed.



Nicklas Karlsson



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

[Emc-developers] GTK3 documentation bug?

[Nicklas SB Karlsson]

Trying gtk3 with glade did not work first time. Reading traceback, 
looking at the source code there error happened and insert a probe to 
print object properties it seemed object did not contain the expected 
property or properties. Looking again I could see in source code object 
of named "window1" was expected. Setting ID in top level window to 
"window1" and it worked.


It could of course be argued documentation should be read to so that 
user know how it should be used but printing an a proper error message 
ought to be a better and more common solution to this problem.



In file src/hal/user_comps/gladevcp.py At row 204 below:

    window = builder.get_object("window1")

I inserted three rows to check and print a message and after required 
compilation checked it seems to work. Below:


    window = builder.get_object("window1")
    if not window:
    print("Did not find object with ID \"window1\" in glade file. 
Expecting a window? at top level? with this name")

    sys.exit(0)
For me it seems a better solution would be to generate the exception 
inside the builder as soon as error is detected but this also work. Not 
sure if object must be a window and on top level.



Suggest this change or adding the check inside the builder is done in 
the source code? Or any objections? I should make a patch to make it happen?


Anyone know if expected object must be at top level? Must be a window?


Nicklas SB Karlsson



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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-03-02 kl. 20:56, skrev Nicklas SB Karlsson:

Den 2022-03-01 kl. 22:06, skrev Jérémie Tarot:

Le mar. 1 mars 2022 à 21:40, Bari  a écrit :



https://github.com/OpenEtherCATsociety/SOEM/blob/master/LICENSE



I don't understand how the last sentences could be compatible with GPL?


lhH EtherCat https://etherlab.org/en/ethercat/ I think is licensend 
under GPLv2 license. Master is implemented as kernel module and 
drivers are included in source code. Guess it should not be to hard to 
re implement to run as a real time thread and rename to Freecat.


in lgH there is some local changes to the original drivers I guess 
come kernel, not sure why. I had some problem SOEM with more than 
three Ethercat devices, message never arrived back in the ring, adding 
a router and it did, not sure if might have something to do with this.


Guess it is against answer myself. Anyway I found.

Checking again it is possible to turn off building of Kernel modules in 
lgH so guess it should be rather simple to get into Linuxcnc. Normally 
an .esi file if I remember postfix correct is used then configuring file 
and ideally it should be possible to configure by using these files and 
add .hal pins. Bought Chinese IO modules, 16 bits in and 16 bits but for 
these are I more or less hardcoded position in Ethercat datagram.



Nicklas Karlsson



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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-03-01 kl. 22:06, skrev Jérémie Tarot:

Le mar. 1 mars 2022 à 21:40, Bari  a écrit :



https://github.com/OpenEtherCATsociety/SOEM/blob/master/LICENSE



I don't understand how the last sentences could be compatible with GPL?


lhH EtherCat https://etherlab.org/en/ethercat/ I think is licensend 
under GPLv2 license. Master is implemented as kernel module and drivers 
are included in source code. Guess it should not be to hard to re 
implement to run as a real time thread and rename to Freecat.


in lgH there is some local changes to the original drivers I guess come 
kernel, not sure why. I had some problem SOEM with more than three 
Ethercat devices, message never arrived back in the ring, adding a 
router and it did, not sure if might have something to do with this.



Nicklas Karlsson



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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-03-01 kl. 23:35, skrev Rod Webster:

The reason why I put this on the agenda is that I observed that the debian
project uncovered a number of licenses which we had to include in our
copyright statement that deviated from the standard GPL licence. I was
quite surprised at this. I would defer to Steffen on license issues and
compatibility.

For now I think we should make contact and make those assessments later.

I propose to write requesting membership of the ETG with the following
contacts
Myself - admin contact
Lead Developer - Nicklas
Steffan - Licensing and the Debian Project.


It is OK for me.


Nicklas Karlsson



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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-03-01 kl. 21:39, skrev Bari:


On 3/1/22 14:25, Nicklas SB Karlsson wrote:

Den 2022-03-01 kl. 21:17, skrev Bari:

On 3/1/22 13:20, Nicklas SB Karlsson wrote:
Already have a simple implementation of an Ethercat driver with 
hardcoded configuration but read something about the license 
problem and have kept it for myself. 



If you developed this yourself without being under an NDA or some 
contract with Beckhoff aren't you free to distribute this under any 
license that you choose?
Used SOEM but added some code, no NDA. 



https://github.com/OpenEtherCATsociety/SOEM/blob/master/LICENSE



Line below seems like a problem.


You can use SOEM for the sole purpose of creating, using and/or selling 
or otherwise distributing an EtherCAT network master provided that an 
EtherCAT Master License is obtained from Beckhoff Automation GmbH.



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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-03-01 kl. 21:17, skrev Bari:

On 3/1/22 13:20, Nicklas SB Karlsson wrote:
Already have a simple implementation of an Ethercat driver with 
hardcoded configuration but read something about the license problem 
and have kept it for myself. 



If you developed this yourself without being under an NDA or some 
contract with Beckhoff aren't you free to distribute this under any 
license that you choose?

Used SOEM but added some code, no NDA.



You don't have to use their term for the driver if it is trademarked. 
Call it something else such as FreeCAT.

Renaming is simple, will do that.



The FSF has lots of resources available. Run the Beckhoff license past 
them for an opinion on conflicts with GPL.



Are there any patents involved in a Linux driver for EtherCAT?


Not sure about the driver, master use ordinary Ethernet but nodes have 
special hardware, guess is it work similar to a shift register as values 
are read/written while datagram pass thru. Pretty sure patent is about 
the nodes.



Real time perfomance is excellent and there are plenty of devices 
available to chose from on the market, Beckhoff have many.



Nickas Karlsson



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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-02-28 kl. 15:47, skrev Steffen Möller:

Hello again,

On 28.02.22 14:28, andy pugh wrote:
On Mon, 28 Feb 2022 at 13:22, Steffen Möller  
wrote:


Personally I know nothing about EtherCAT. I have always been a little
afraid of the licensing complexities mentioned here:

https://etherlab.org/en/ethercat/

Etherlab itself is GPLv2, but _using_ it seems to bring a different
licensing restriction into play. And I don't know enough about
licensing to know if that's a problem.


I called them up - first the Beckhoff group (they have nice stuff on 
https://www.beckhoff.com/en-gb/) and from there I was pointed to the 
EtherCAT Technology Group (https://www.ethercat.org/de/contact.html), 
so I called them, too. Without that membership we would be in said 
uncharacterized unmitigated license trouble


Already have a simple implementation of an Ethercat driver with 
hardcoded configuration but read something about the license problem and 
have kept it for myself.



  that Andy referenced but with that membership they would be very 
sweet to us. From what I understand, they try to be good people and 
just in case someone messes something up they do not want to guess how 
to reach out. So we are asked to become a member of the EtherCAT 
Technology Group (ETG) - for which we would identify someone who would 
serve as a communicator between them and our community and write a 
"3-line email" with our request to integrate an EtherCAT driver that 
is available at some URL with LinuxCNC as described on 
https://linuxcnc.org.


I do not see that Debian would become a member of their Technology 
Group. And it would not make too much sense to me to have any extra 
outreach from Debian to that ETG, but we can ask for an OK to have 
that distribution channel and also ask for Fedora at the same time.


Now - big question: Is there an agreement that it would be beneficial 
for LinuxCNC to become a member of the ETG? It is free. And there 
likely a series of perks for training material that may not be of our 
immediate concern. They invited me to help with that initial contact 
but that LinuxCNC-representative to them could then be anyone we pick. 
Andy? Rod? You both? Jeff? All three of yours?

I could volunteer.


Nicklas SB Karlsson


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

Re: [Emc-developers] EtherCAT - would not be a prob with free membership in EtherCAT Technology Group Re: LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Den 2022-03-01 kl. 13:27, skrev Rod Webster:

So I shared Steffen's post on the Ethercat section of the forum calling for
technical volunteers. Maybe some of them are in this group already.
https://forum.linuxcnc.org/ethercat/45239-lets-get-ethercat-into-the-linuxcnc-distribution-need-technical-people-to-help


I have to volunteer. Also have knowledge about CANopen which is useful 
since many devices use this "protocol" over ethercat.



Nicklas SB Karlsson



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

Re: [Emc-developers] LinuxCNC is in Debian!

[Nicklas SB Karlsson]

Metoo use debian. Great!

On Sun, 27 Feb 2022 11:36:37 -0700
Sebastian Kuzminsky  wrote:

> On 2/27/22 04:00, Debian FTP Masters wrote:
>  > Accepted:
>  >
> > Format: 1.8
> > Date: Fri, 25 Feb 2022 18:40:12 +0100
> > Source: linuxcnc
> > Binary: linuxcnc-doc-en linuxcnc-doc-es linuxcnc-doc-fr linuxcnc-doc-zh-cn 
> > linuxcnc-uspace linuxcnc-uspace-dbgsym linuxcnc-uspace-dev
> > Architecture: source all amd64
> > Version: 2.9.0~pre0+git20220224.3ba0951743-1
> > Distribution: unstable
> 
> Yayyy!  Thank you Steffen, and Petter and everyone who's been working on 
> getting LinuxCNC into Debian!
> 
> If you're running sid/unstable you can now just `apt-get install 
> linuxcnc-uspace`, right from the debian.org package archive:
> 
>  
> 
> 
> It'll hopefully make it into bookworm/testing in a couple of days. 
> We'll work on bullseye after that.  :-)
> 
> 
> -- 
> Sebastian Kuzminsky
> 
> 
> ___
> 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

[Nicklas SB Karlsson]

Den 2022-02-06 kl. 18:50, skrev Håvard F. Aasen via Emc-developers:

On 2022-02-06 17:11, Nicklas SB Karlsson wrote:

Den 2022-02-06 kl. 13:34, skrev Tim Blume:
Are you trying to build the old gtk3 branch, that is already merged 
into master by any chance?


Not sure.

Searching the source tree I found lib/python/multifilebuilder_gtk3.py
is in master-gtk3 branch but not in ethercat2.8 or master branch.

If you compare the branches master and master-gtk3, you can see that 
the file 'lib/python/multifilebuilder_gtk3.py' has been merged into 
'lib/python/multifilebuilder.py'. If ethercat2.8 is based on version 
2.8, it should still use gtk2.


Trying git log --oneline --graph --decorate --all|less I could see the
branches but are little bit to many to figure out.


There is actually a pr that has been included in the master-gtk3 
branch, after it was originally merged. Is it possible for a dev to 
take a look at it, and if it's still good, merge it in with master and 
then delete the master-gtk3 branch? It seems to create some confusion 
of which master branch to use. If there isn't any reason to keep it 
around.


The master-gtk3 confused me, may be because I started with gtk2 before 
branch was created. Trying the master branch it indeed seems to work.


Nicklas Karlsson




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

Re: [Emc-developers] GTK3

[Nicklas SB Karlsson]

Den 2022-02-06 kl. 13:34, skrev Tim Blume:
Are you trying to build the old gtk3 branch, that is already merged 
into master by any chance?


Not sure.

Searching the source tree I found lib/python/multifilebuilder_gtk3.py is 
in master-gtk3 branch but not in ethercat2.8 or master branch.


Trying git log --oneline --graph --decorate --all|less I could see the 
branches but are little bit to many to figure out.



Nicklas Karlsson



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

Re: [Emc-developers] LinuxCNC Participation in Google Summer of Code 2022?

[Nicklas SB Karlsson]

Den 2022-02-06 kl. 16:07, skrev andy pugh:

On Sun, 6 Feb 2022 at 14:36, Jérémie Tarot  wrote:


Finally, I think @turboss had started giving a try at a node based HAL
config UI... Wouldn't that be nice ?

There have been at least 4 attempts at this, but none seem to try to
carry on where the previous one left off.

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Eagle2HAL
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Crapahalic
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server
https://github.com/dev-git-usr/HAL-Editor


Have done some work with gEDA gschem or later renamed to lepton 
schematic. Basic idea is an extra netlist backend to generate the hal 
file from the schematic, also need to make a library with symbols of course.


If doing changes to the .hal files it might be worth looking at 
structural VHDL and reuse the syntax.



Nicklas Karlsson



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

Re: [Emc-developers] thinking about the next LinuxCNC release

[Nicklas SB Karlsson]

gtk3 is in the master-gtk3 branch and seems well on it's way. Need to 
upgrade to latest debian bullseye to get it to work if running Debian.


Den 2022-02-06 kl. 13:55, skrev Steffen Möller:

Heya,

On 06.02.22 11:43, Jérémie Tarot wrote:

Le mer. 2 févr. 2022 à 19:18, Sebastian Kuzminsky  a
écrit :


What are the big projects that need to get finished for the next
release?  Some things I know vaguely about, but don't know the 
status of:

...

* Transition docs translations to po4a (optional but highly desired)

What is the status of those projects?


French docs migration has finally been done

But have all the changes to the English files been merged, yet? Is there
a PR of yours against master out? I have mine on
https://github.com/LinuxCNC/linuxcnc/pull/1516 but somehow managed to
wreck it, did not find the problem, yet. I would hence be very happy for
your changes to go in first.

so @pere should now be able to
carry on with docs build to produce the first version of the 
auto-generated

translations...


I also want to see this, admittedly. Where I see part of the problem is
with all the updates we have done to the English texts in the mean time,
not knowing how good po4a/weblate is to get this synced up. Without that
sync, I guess the corresponding .po element is lost - if not with the
first weblate pull request then with the second. But then again, if this
is problematic now, then this is problematic with every future change
when someone changes

*something
like this

to

* something
  like that

We can just hope for the best, I tend to think and should go ahead. What
then happens - happens and I presume we can either live with it and
improve po4a over time or fall back to how everything is now. Most
important are French's (in the sense of
https://www.youtube.com/watch?v=38Wmi6-u7Mk) backports to English so all
content is preserved.


Meanwhile @smoe and I are looking at docs writing guidelines and style
guide, as well as designing upgraded docs pages templates/skeletons. 
Once

perfected, and auto-generation working, we'll review and upgrade all
english docs pages, as well as translate and add the good chunks pulled
from the french version.
Hopefully, 2.9 could be released with an upgraded docs system (po4a,
weblate and adoc templates), and auto generated spanish and french
translations.


That would be darn cool, in my mind 2.9 would be more like a technical
experiment, still. For instance we have yet no clue about how many
contributors would find their way to LinuxCNC if the 2.9 release
promotes this weblate initiative. I would want to stress in the release
notes that free localized documentation may be as important as the
software itself because of the many concepts and problem-awareness it
transports.

I should PM @pere about it all who is not subscribed to this list.

This would pave the road to 3.0 for updated and extended support 
contents...


I think it would be very nice to have a list of features that we aim to
achieve for the 3.0 version. Personally, I kind of expect a 2.10, 
still :)


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

[Nicklas SB Karlsson]

Den 2021-05-31 kl. 14:23, skrev 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 



Tried it but it does not help.

Compile and run works, running glade the hal widgets do however not show 
up in the use interface. There widgets should be: HAL Python, VCP 
Actions and GtkSourceView do however show up but empty.


There is a list of complaint at the prompt it can't find different 
symbols and types. Further down there is a list "Tried to include 
undefined widget class" xxx in a widget group. There is also a few other 
complaints at bottom but they are there both then running from ordinary 
and from prompt there rip-environment script have been run.







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



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

Re: [Emc-developers] thinking about the next LinuxCNC release

[Nicklas SB Karlsson]

Den 2022-02-03 kl. 21:59, skrev Håvard F. Aasen via Emc-developers:

On 2022-02-02 19:02, Nicklas SB Karlsson wrote:

Den 2022-02-02 kl. 19:16, skrev Sebastian Kuzminsky:
What are the big projects that need to get finished for the next 
release?  Some things I know vaguely about, but don't know the 
status of:


* Transition to gtk3 (required)


Read in an old thread from May last year I found this fork
https://github.com/LinuxCNC/linuxcnc/pull/1164 but are still uncertain
about the status.



I believe classicladder is the last application that uses gtk2, which 
this line [1] confirms.
Upstream has a newer version supporting both gtk2 and gtk3, but the 
diff has become quite large over the years. Half a year ago or so, I 
started to backport some of the new features, but stopped, I didn't 
feel I could test the changes thoroughly enough.
It should be possible to update it to gtk3, though I'm not sure which 
strategy is best, try to stay as close to upstream as possible, or 
only change the gtk part and continue with the version we got.


Use Glade for custom buttons/LEDs an others. Switched to master-gtk3, 
compile and run works, running glade the hal widgets do however not show 
up in the use interface. The there widgets should be: HAL Python, VCP 
Actions and GtkSourceView do however show up but empty.


There is a list of complaint at the prompt it can't find different 
symbols and types. Further down there is a list "Tried to include 
undefined widget class" xxx in a widget group. There is also a few other 
complaints at bottom but they are there both then running from ordinary 
and from prompt there rip-environment script have been run.


May have a little bit of time to spend on it the coming months.


Nicklas Karlsson



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

Re: [Emc-developers] thinking about the next LinuxCNC release

[Nicklas SB Karlsson]

Den 2022-02-03 kl. 21:59, skrev Håvard F. Aasen via Emc-developers:

On 2022-02-02 19:02, Nicklas SB Karlsson wrote:

Den 2022-02-02 kl. 19:16, skrev Sebastian Kuzminsky:
What are the big projects that need to get finished for the next 
release?  Some things I know vaguely about, but don't know the 
status of:


* Transition to gtk3 (required)


Read in an old thread from May last year I found this fork
https://github.com/LinuxCNC/linuxcnc/pull/1164 but are still uncertain
about the status.



I believe classicladder is the last application that uses gtk2, which 
this line [1] confirms.
Upstream has a newer version supporting both gtk2 and gtk3, but the 
diff has become quite large over the years. Half a year ago or so, I 
started to backport some of the new features, but stopped, I didn't 
feel I could test the changes thoroughly enough.
It should be possible to update it to gtk3, though I'm not sure which 
strategy is best, try to stay as close to upstream as possible, or 
only change the gtk part and continue with the version we got.


Latest version of gtk is gtk4 but if already almost that's good enough. 
Still use GTK2 and it works but have to install old package so one day I 
guess it will break if continue to update operating system.



Nicklas Karlsson



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

Re: [Emc-developers] thinking about the next LinuxCNC release

[Nicklas SB Karlsson]

Den 2022-02-02 kl. 19:16, skrev Sebastian Kuzminsky:
What are the big projects that need to get finished for the next 
release?  Some things I know vaguely about, but don't know the status of:


* Transition to gtk3 (required)


Read in an old thread from May last year I found this fork 
https://github.com/LinuxCNC/linuxcnc/pull/1164 but are still uncertain 
about the status.





* Transition to python3 (required)

* Transition docs translations to po4a (optional but highly desired)

What is the status of those projects?

What in-progress projects are missing from this list?





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

Re: [Emc-developers] more convenient homing for machines with limit switches and reference switch.

[Nicklas SB Karlsson]

Den 2021-10-19 kl. 19:21, skrev Rainer Stelzer:

Hi Dan,

I had similar issues when:

- a PID controller is involved,
- a PID input value jumps (as it is the case for the positioning PID 
controller when new location is set at the home position)

and
- the order of the hal function calls are  not correct.

Example:
I recently noticed that when using M19 spindle orientation.
Works perfectly after startup.
Tested dozens of positions to tune the PID.
But after the spindle made some hundred revolutions and the spindle 
stops to orient for toolchange,

the PID controller generates a big jump.
The reason was, that the orient component calculated a new set 
position by taking the actual position before  the call to the 
hardware interface was done.
So the PID saw a giant difference on the feedback and the command 
input and acted accordingly with a giant output.
It was only for one servo-thread period, but depending on your PID 
setup, this can cause a significant spike.


This is really a tricky issue, esp. when you are focused on PID tuning 
and this kind of side effects come into play .


If spindle angle is set to zero at encoder zero pulse and position 
control is used there will be one or in case of delay maybe up to a few 
servo periods glitch.



There is another issue. Then spindle orientation is set there is a jump 
in reference value, "trajectory" planning and feed forward may be a good 
idea. My machine has some backlash in the gear box further complicating 
the control loop.



Nicklas Karlsson



___
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

[Nicklas SB Karlsson]

Den 2021-08-01 kl. 10:29, skrev 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.

No objections, happy you work on gtk3.


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

Re: [Emc-developers] Question for the devs

[Nicklas SB Karlsson]

>  5420 gives me current position from my work offset zero. I want current
> position from my machine home (g53) position

Then you use "G53 Move in Machine Coordinates"? Or?

> 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 Sun, Jul 25, 2021, 5:02 PM  wrote:
> 
> > Isn't that #5420?
> >
> > -Original Message-
> > From: Feral Engineer 
> > Sent: Sunday, 25 July 2021 7:39 AM
> > To: EMC developers 
> > Subject: [Emc-developers] Question for the devs
> >
> > Hello devs,
> >
> > I have a question. In Fanuc land, #5021 is the X axis system variable for
> > machine home position (axis 1, really), 5022 is axis 2, etc. Linuxcnc does
> > not have these variables. I'm wondering how hard it would be to add them?
> > Having access to the machine coordinate system is helpful in writing logic
> > for various things (as is goto, but I'm not pressing my luck). Unless
> > there's an alternate variable I could use, like #<_axis_1_mach_pos>
> > something like that? Also, not sure how familiar you guys are with G65 and
> > G66 macro calls. Is this something up for consideration in the future? Just
> > curious is all. I'm a macro maniac.
> >
> > Tyia
> >
> >
> > 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
> >
> > ___
> > 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


-- 
Nicklas SB Karlsson 


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

Re: [Emc-developers] EtherCAT modules help needed --> some kind of write access

[Nicklas SB Karlsson]

> That's interesting, Nicklas!
> 
> I never met SOEM before the same for lcec before I started this integration.
> I understand that those technologies are completely different
> implementations, aren't they?
> 
> Was it hard to develop your solution? Where did you start, what was needed?
> 
> BTW, I found and watched this video, which I found interesting:
> https://www.youtube.com/watch?v=PHFZMir9mjk
> While I am not sure what is free and what we have to pay for.
> 
> Anyway, can you share some code with me?

Back from garage, warmer, no snow or similar problem but hot. All of a sudden 
speed of computer fan started and it went and problem resisted even though 
computer hav been to cellar for a few hours and last some changes in file. Also 
birds nest and bird dropping in the gutter for cutting chip management.


Have some code to share and thinking about the right place must be a fork in 
Linuxcnc, rememember some copyright notice but sharing what I have written 
can't be a problem even though license agreement is required to used it with 
some kind of other library. It would be possible to get my own fork with write 
access on Github or similar?


Nicklas SB Karlsson


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

Re: [Emc-developers] flipflop

[Nicklas SB Karlsson]

Den 2021-05-29 kl. 16:56, skrev Jeff Epler:

On Tue, Apr 06, 2021 at 09:05:51PM +0100, andy pugh wrote:

I wonder why the output pin of flipflop.comp is of type io?

Perhaps it was intended for a specific purpose?

flipflop only drives a value onto its output when it is clocked or when
its set input is true.  The theory was probably that there was some way
to make other state-holding elements out of this, such as an SR-latch.
It change output value at positive flank but drive all the time. May 
also be forced high or low according to manual.

I have no idea whether this is used.


Hard to tell if it is used anywhere but is one of the basic building and 
it may be useful then there is a need to sample/clock a value on rising 
edge though there may be a few others to chose from.



Nicklas Karlsson



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

Re: [Emc-developers] GTK3

[Nicklas SB Karlsson]

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?



Nicklas Karlsson



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

[Nicklas SB Karlsson]

Den 2021-05-12 kl. 11:56, skrev 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?


Use 2.8 because I know 2.9 is a moving target and that works great.


Nicklas Karlsson



___
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

[Nicklas SB Karlsson]

Den 2021-05-11 kl. 15:57, skrev 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.


Great, maybe eventually I have time to help you.


Nicklas Karlsson




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

Re: [Emc-developers] Indentation of subsections in the HTML man pages

[Nicklas SB Karlsson]

Den 2021-04-16 kl. 19:17, skrev Hans Unzner:
Unfortunately the subsections (.SS) of the man pages are not treated 
as such when convertet to HTML. Just bold text.

Especially the halui man page lacks clarity because of that.

I created a little macro that handles the subsections.
What version would you prefer?

1. Indent the text of the subsection:
https://hansu.github.io/linuxcnc-doc/man/man1/halui_subsection1.1.html
2. Indent the subsection heading somewhere between the section heading 
and the text like the view in the terminal:

https://hansu.github.io/linuxcnc-doc/man/man1/halui_subsection2.1.html
3. Use  HTML tags and let the indentation be controlled by 
the stylesheet:

https://hansu.github.io/linuxcnc-doc/man/man1/halui_subsection3.1.html


Option 3. let the indentation be controlled by the stylesheet. Think 
.css have been invented more or less for reasons like this. If need to 
or in doubt how to change 
https://www.w3schools.com/csSref/pr_text_text-indent.asp



Nicklas Karlsson



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

Re: [Emc-developers] Personality in userspace components.

[Nicklas SB Karlsson]

Den 2021-02-21 kl. 01:50, skrev andy pugh:

There seems to be a problem using "personality" in a userspace
component (which makes it hard to have a variable number of pins)


? Made simple driver with variable number of pins read from 
configuration file at startup. I however found values in .hal file is 
not available until real time have started so as is now I use extra 
separate configuration file, very simple.


Use function hal_pin_new(..) to add pins. Call is located in 
rtapi_app_main(...) function and some module initialization is done first.



Nicklas Karlsson



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

Re: [Emc-developers] Linuxcnc 2.8.0 buster iso: please add memtest and possibilty to wipe partition table and mc

[Nicklas SB Karlsson]

Some expansion card?

Den 2020-10-28 kl. 21:52, skrev CHRIS EPICIER via Emc-developers:

Hi all

My first post here.

I have two wishes:

  1. I recently ran into problems with a dell precision T3500 of a
 colleague of mine. I recommended this PC because of this post, where
 the said pc is tested with excellent results.

 We had figures well above 100'000 nS. So I had to start digging into
 the problems. In the course, I wanted to use memtest86+ off the USB
 install stick, based on buster ISO 2.8.0 2020-09-07. I tried to
 invoke memtest from the stick, but it fails, both when called from
 "Advanced options | Memory diagnostic Tool (memtest86+)" or through
 "Advanced options | Hardware detection tool (HDT) | Memory | Run test".

 If going through HDT, I get

 Loading /live/memtest... failed: no such file or directory
 boot:

 "Loading /live/memtest... failed: no such file or directory
 boot:"

 On the stick, in grub.cfg I could not find entries for memtest86 or
 memtest86+.

 I think, for debugging memtest is very handy, so I kindly ask, if
 memtest could not be added to the buster ISO?

  2. When installing on a used HD/SSD, I regularly get to the situation,
 where a disc has an incompatible partition table written. The
 graphical installer runs into a problem then, writing a new
 partition table. If on Ctrl-F1/2/3 terminal one could fire up say
 "fdisk" and thus write an empty dos partition table, that whole
 installation process could run through.

 A "nice to have" only. I get around this in aborting the
 installation process, shutting down the PC, extracting the dis,
 attach it to another PC, write an empty partition table to it and
 the then restart the installation process from scratch.

  3. Midnight commander in Ctrl-F1/2/3, please.

I'd call it nice to haves, not need to have. But if available: sooo good!

Greez

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] buster vs pi3b report

[Nicklas SB Karlsson]

Use buster, if I remember correctly I had to manually install an older version 
of a few packages.


On Sat, 31 Aug 2019 13:36:23 -0400
Gene Heskett  wrote:

> On Friday 30 August 2019 18:54:31 John wrote:
> 
> > Hi Gene,
> >
> > git clone https://github.com/LinuxCNC/linuxcnc.git
> > the/directory/to/clone/to
> >
> > Probably similar to my Rpi4 instructions for raspian 10.
> >
> > http://gnipsel.com/linuxcnc/uspace/rpi4-emc.html
> >
> > JT
> 
> Going thru the menu above, at  apt install python-gtksourceview2 
> python-xlib gstreamer0.10-plugins-base, I get a bailout:
> Package gstreamer0.10-plugins-base is not available, but is referred to 
> by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> Package python-gtksourceview2 is not available, but is referred to by 
> another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> 
> E: Package 'python-gtksourceview2' has no installation candidate
> E: Package 'gstreamer0.10-plugins-base' has no installation candidate
> 
> Is something missing in my debian-arm buster sources.list?
> 
> 
> Thanks.
> > On 8/30/19 1:13 PM, Gene Heskett wrote:
> > > Greetings;
> > >
> > > I found today, after finding the u-sd card with a netinstall of
> > > debian buster on it, that debian-arm for v8's (arm64, not hf) has a
> > > realtime preempt kernel available. So I installed it and rebooted,
> > > then installed the mesa-utils deb to get glxgears etc.
> > >
> > > Testing glxgears pulled out to about 95% of the screen was a bit
> > > surprising because I've assumed debian would never touch the
> > > broadcom code that can run glxgears at 27 fps full screen when
> > > running the latest raspian buster install.  But I did get around 9
> > > fps, which is about 7.5 fps faster than I am getting running either
> > > raspian jessie or raspian stretch.  Thats quite promising and I'll
> > > gopher it.
> > >
> > > So since buster is running quite nicely, (for a change, this new
> > > buster install just plain feels right!)
> > >
> > > This looks promising enough to git clone master and build it. I've
> > > done that on raspian stretch, building an installable deb for armhf.
> > > So once I have fstab mounting the ssd's ok, I'd need a refresh on
> > > the git clone command and about a day. maybe more, as the build dies
> > > looking for resources not yet installed, they then need to be
> > > installed and the build restarted.
> > >
> > > So refresh me on the git clone command line please.
> > >
> > > Thank you.
> > >
> > > Cheers, Gene Heskett
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


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

[Emc-developers] ... how to catch errors with waitcomplete command in python --> type hierachy, visual

[Nicklas SB Karlsson]

You use integrated development environment like Eclipse or codeblocks?

In such case usually with some luck it if possible to rightclick or shortcut 
key on variable/type and show declaration. It also possible variables, type 
maybe with hierachy is a available in extra tab.


I tried to program Linuxcnc in Eclipse and it works relatively well but it is 
written in Java so sometimes the coffe ring appear and keystrokes may be a 
little bit delayed but it's a small problem.

I recently also download and tried codeblocks which make relatively good 
impression. gnat-gps is another option.


In the code I could see a typecast which I usually only use if there is a good 
reason for it. Most usually is I come by a number and have figured out it shoul 
repsent som kind of type, most usually serially received data in some kind of 
message protocol.


On Sat, 8 Dec 2018 16:51:11 +
Chris Morley  wrote:

> 
> 
> From: Nicklas SB Karlsson 
> Sent: December 8, 2018 4:23 PM
> To: EMC developers
> Subject: Re: [Emc-developers] how to catch errors with waitcomplete command 
> in python
> 
> >No real idea but an exception is a common method to handle errors, it might 
> >however be a problem in a real time system.
> 
> In this case the python is a bit of a red herring...
> I'm using python to call the wait_complete() function but it actually is 
> programmed in C++
> Here is the function:
> 
> static int emcWaitCommandComplete(pyCommandChannel *s, double timeout) {
> double start = etime();
> 
> do {
> double now = etime();
> if(s->s->peek() == EMC_STAT_TYPE) {
>EMC_STAT *stat = (EMC_STAT*)s->s->get_address();
>int serial_diff = stat->echo_serial_number - s->serial;
>if (serial_diff > 0) {
> return RCS_DONE;
>}
>if (serial_diff == 0 &&
>( stat->status == RCS_DONE || stat->status == RCS_ERROR )) {
> return stat->status;
>}
> }
> esleep(fmin(timeout - (now - start), EMC_COMMAND_DELAY));
> } while (etime() - start < timeout);
> return -1;
> }
> 
> It seems to decide if the command is done by it's serial number.
> But it does check it's status.
> It seems the RCS is probably a message frame that NML uses.
> so maybe we could inject the commands error code into the
> stat-> structure.
> I just haven't been able to follow the code enough.
> 
> Thanks
> Chris M
> 
> ___
> 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] how to catch errors with waitcomplete command in python

[Nicklas SB Karlsson]

On Sat, 8 Dec 2018 16:51:11 +
Chris Morley  wrote:

> 
> 
> From: Nicklas SB Karlsson 
> Sent: December 8, 2018 4:23 PM
> To: EMC developers
> Subject: Re: [Emc-developers] how to catch errors with waitcomplete command 
> in python
> 
> >No real idea but an exception is a common method to handle errors, it might 
> >however be a problem in a real time system.
> 
> In this case the python is a bit of a red herring...
> I'm using python to call the wait_complete() function but it actually is 
> programmed in C++
> Here is the function:
> 
> static int emcWaitCommandComplete(pyCommandChannel *s, double timeout) {
> double start = etime();
> 
> do {
> double now = etime();
> if(s->s->peek() == EMC_STAT_TYPE) {
>EMC_STAT *stat = (EMC_STAT*)s->s->get_address();
>int serial_diff = stat->echo_serial_number - s->serial;
>if (serial_diff > 0) {
> return RCS_DONE;
>}
>if (serial_diff == 0 &&
>( stat->status == RCS_DONE || stat->status == RCS_ERROR )) {
> return stat->status;
>}
> }
> esleep(fmin(timeout - (now - start), EMC_COMMAND_DELAY));
> } while (etime() - start < timeout);
> return -1;
> }
> 
> It seems to decide if the command is done by it's serial number.
> But it does check it's status.
> It seems the RCS is probably a message frame that NML uses.

You know what serialnumber is? For some reason I got the feeling it might be 
some kind of counter counting upwards.


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

Re: [Emc-developers] how to catch errors with waitcomplete command in python

[Nicklas SB Karlsson]

No real idea but an exception is a common method to handle errors, it might 
however be a problem in a real time system.

On Sat, 8 Dec 2018 15:39:30 +
Chris Morley  wrote:

> I am working on some probing routines in qtvcp.
> I am calling an MDI command to probe and then using the command,
> wait_complete()
> 
> wait_complete can return some status info (from docs):
> Return -1 if timed out, return RCS_DONE or RCS_ERROR according to command 
> execution status.
> 
> RCS_ERROR seems to only give errors if the Gcode syntaxt is wrong, not if the 
> command
> finished in error.
> 
> The usual way to catch errors is to poll the error channel but if I do that 
> then the usual error
> consuming code misses the error (errors can be consumed by only one object)
> Because of the probing function is in the same thread as error checking, i 
> can't catch the
> error untill it's too late.
> 
> I tried adding:
> emcmotStatus->commandStatus = EMCMOT_COMMAND_INVALID_COMMAND;
> to the probing code in control.c to no joy.
> I can't seem to find where wait_complete's RCS return codes are generated.
> 
> It seems silly to be able to wait for a command to finish but to not know if 
> it errored.
> Any ideas how this could be added?
> In this case I don't need to know what the error was, just that there was 
> one, but
> of course knowing what the error was could be useful too.
> 
> Chris Me
> 
> ___
> 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] [Emc-users] [EMC] NML_FILE = emc.nml

[Nicklas SB Karlsson]

Assume it is python now, I personally prefer the static type checking in C++ 
over the dynamic type checking in python but have sometimes have some problem 
with the syntax. If you use dynamic memory allocation, you use shared_ptr?

On Fri, 7 Dec 2018 20:08:35 +0100
theman whosoldtheworld  wrote:

> No problem for these I'm on SIM only not realtime  for first develop my
> c++ inteface,... during develop period test it with axis open  than I
> try to leave out axis gui and insert my c++ gui instead  than I try to
> mount all on real machinery ... all these during christmas period ... NICE
> ;)
> 
> bkt
> 
> Il giorno gio 6 dic 2018 alle ore 20:47 Nicklas Karlsson <
> nicklas.karlsso...@gmail.com> ha scritto:
> 
> > On Wed, 5 Dec 2018 12:58:51 +0100
> > theman whosoldtheworld  wrote:
> >
> > > Perfect ... you are in right ... problem solved finally.
> > >
> > > you use keystick on nml file . you have a 3d printer? linear or
> > delta?
> > >
> > > I work on these project from 2017 but only 2/3 week per years and only
> > > during my lauch time (max 30min)  so my teaching about emc file
> > > ecosistem is bad. Every time a very little problem become big enough ...
> > I
> > > do not know if I can ever offer you a beer for this ... but you deserve
> > it
> > > ... maybe even two.
> > >
> > > Hello and thanks
> > >
> > > bkt
> >
> > I tried the NML files a while ago in almost latest development version and
> > got the impression server running the real time worked but had problem with
> > the axis gui.
> >
> > I do not thinkg it help but could dig out the files but probably not
> > before sunday.
> >
> >
> > ___
> > 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] coding style

[Nicklas SB Karlsson]

On Fri, 04 May 2018 13:41:57 +0200
Rene Hopf  wrote:

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

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.

As I understand you already discovered clang for formatting.

> 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

Eclipse have some kind of builtin gnu variant but insert tabs then lines get 
long enough even though the option to not have been marked.

> 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

Re: [Emc-developers] Mesa RS-422 hal example (canopen messages?)

[Nicklas SB Karlsson]

I am rather aware about some of it including canfestival but did not had time 
canfestival. I have not yet read about standard method to implement CANopen 
over serial communication like UART or SPI so it would be interesting if 
anybody have seen something?

As is now I do: 16 bits COB-ID + 8 bytes payload + 16 bits modbus CRC.

I could chose any message format but to use standard is always better and what 
I want is in particual the dictionary for configuration parameters. I have 
simple implementation for this over UDP/IP via Ethernet and it work great.



On Sat, 16 Sep 2017 09:00:22 +0200
theman whosoldtheworld  wrote:

> very interesting for me about linux can is these link ... because a
> complete link of helping sites and library ...
> https://github.com/machinekit/machinekit/issues/589  mhaberler provided
> ... these project seems nice  https://rtime.felk.cvut.cz/gitweb/
> 
> bkt
> 
> 
> 2017-09-13 9:12 GMT+02:00 Marius Liebenberg :
> 
> >
> > Hmm, the documentation and components mention do not seem to exist in
> >> master branch. http://linuxcnc.org/docs/devel/html/drivers/hostmot2.html
> >> I also had a look in 2.7 git and could not locate the uart comps. Any
> >> links to git would be appreciated
> >> Moving forward, plasma activity is going to be in master branch due to
> >> joint axis and Dewey's external offsets branch so it would be good to
> >> restore this.
> >>
> >> I'm assuming Marius wants to talk to a Hypertherm plasma cutter using
> >> their documented modbus protocol.
> >>
> > That is precisely what I have to do. A HPR260 plasma source.
> >
> >>
> >> When I've thought about this problem, I did not think serial comms should
> >> be in real time but in user space. In my config, a gcode M67 E0 Q440 is
> >> sent to the glade screen python handler where it is decoded as "Set plasma
> >> amps to 40 amps". Similarly for air pressure. I'm not doing anything with
> >> this command yet. There are any number of modbus libraries for python so I
> >> was hoping if I knew how to access the uart, I could write commands with a
> >> high level python routine. I'm assuming Python could access the uart
> >> functions Andy mentioned?
> >>
> >> Pretty sure the Gmocappy plasma GUI and its supporting plasma.py I've
> >> modified was written by Marius so thanks
> >>
> > I will have to add quite a bit of functions and a screen or two to
> > Gmoccapy in order to handle the requirements for the Hypertherm HPR260
> >
> >
> >>
> >>
> >> Rod Webster
> >> 0435 765 611
> >> Vehicle Modifications Network
> >> http://www.vehiclemods.net.au/
> >>
> >>
> >>
> >> On 13 September 2017 at 04:02, Marius Liebenberg 
> >> wrote:
> >>
> >>>
> 
>  On 12 September 2017 at 10:47, Marius Liebenberg <
>  mar...@mastercut.co.za> wrote:
> 
>  > >You need a Mesa bitfile which puts UARTS on some of the 7i44 ouputs
> 
>  > Does this apply to the 7i80 or 7i44?
> 
>  7i80 bitfile.
> 
>  > > Whatever you use, you need to find a way to work out where you are
>  in
>  > > the byte stream.
> 
>  > Does this imply that the data stream on the UART is not all mine and
>  that there are other info being sent ?
> 
>  No, it is all yours, but once your data spans multiple packets you need
>  to work out where you are in the byte stream. This can be done simply by
>  timing, if there is a longer pause between the start and end packets than
>  the inter-byte gap, or some protocols have byte patterns that can not 
>  exist
>  in the data as frame markers.
> 
> >>> Or a state machine if the frames are predictable as mine is.
> >>> Something like this:-
> >>> > = Start of message
> >>>
> >>> 3 byte command ID
> >>>
> >>> Data
> >>>
> >>> 2 byte checksum
> >>>
> >>> < = End of message
> >>>
> >>> Sample: >0011C2<
> >>>
> >>>
> >>>
> >>>
>  > Does the mesa_uart.comp serve as an example only or is it a
>  > loadable component.
> 
>  If you have uarts in your firmware it should work. I have used a very
>  similar component to send data from an Arduino to a Mesa card.
> 
> >>> That is interesting and might open a whole lot of scope.
> >>>
> >>>
>  --
>  atp
>  "A motorcycle is a bicycle with a pandemonium attachment and is
>  designed for the especial use of mechanical geniuses, daredevils and
>  lunatics."
>  — George Fitch, Atlanta Constitution Newspaper, 1916
> 
> >>>
> >>> ---
> >>> This email has been checked for viruses by Avast antivirus software.
> >>> https://www.avast.com/antivirus
> >>> 
> >>> --
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>> ___
> >>> Emc-developers mailing list
> >>> 

Re: [Emc-developers] rtcan.h

[Nicklas SB Karlsson]

> Actually I search for a field bus acalternative to ethercat, so I gave
> an eye to this:
> 
> http://www.xenomai.org/documentation/trunk/html/api/rtcan_8h.html#details
> 
> From what I read no one has implemented rtcan for rt-preempt.
> 
> Also I read on linuxfoundation sites that on rt-preempt is possible
> set an realtime level of execution on a specific
> process without too much mood.

CAN is an alternative but 1Mbit/s is at the limit for a six axis machine. CAN 
on a micro controller may be done a lot cheaper than Ethercat.


Nicklas Karlsson

--
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] Axis nml communication

[Nicklas SB Karlsson]

I am trying to run linuxcnc with remote communication via NML between user 
interface and rest of the machine. I have read manual and could see there is 
NML communication between user interface and rest of machine, I have also been 
able to run server but not client.

I know axis command is the user interface and have started to look at the 
source code for this command, the question is do this axis command also do the 
NML communication? Do anybody know the status if it is possible to get this NML 
communication to run over TCP?

I have started look into source code but only have an hour or so daily so I 
guess it will be a couple weeks before I figure out what part is where for axis 
command.


Nicklas Karlsson

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