You can subscribe to this list here.
| 2000 | Jan | Feb | Mar | Apr | May | Jun | Jul | Aug | Sep | Oct | Nov (29) | Dec (16) | 
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 | Jan (2) | Feb (6) | Mar (2) | Apr | May (3) | Jun (1) | Jul (32) | Aug (15) | Sep (5) | Oct (5) | Nov | Dec (1) | 
| 2002 | Jan (12) | Feb | Mar (6) | Apr (1) | May (5) | Jun (1) | Jul (3) | Aug (3) | Sep (4) | Oct (2) | Nov (19) | Dec (14) | 
| 2003 | Jan (1) | Feb | Mar | Apr | May (56) | Jun (41) | Jul (324) | Aug (46) | Sep (123) | Oct (62) | Nov (53) | Dec (102) | 
| 2004 | Jan (84) | Feb (67) | Mar (8) | Apr (68) | May (52) | Jun (119) | Jul (19) | Aug (43) | Sep (51) | Oct (189) | Nov (74) | Dec (67) | 
| 2005 | Jan (43) | Feb (43) | Mar (139) | Apr (20) | May (56) | Jun (160) | Jul (94) | Aug (91) | Sep (53) | Oct (79) | Nov (198) | Dec (106) | 
| 2006 | Jan (103) | Feb (116) | Mar (135) | Apr (97) | May (72) | Jun (49) | Jul (51) | Aug (45) | Sep (67) | Oct (91) | Nov (51) | Dec (81) | 
| 2007 | Jan (100) | Feb (57) | Mar (72) | Apr (81) | May (49) | Jun (13) | Jul (5) | Aug (32) | Sep (37) | Oct (42) | Nov (84) | Dec (41) | 
| 2008 | Jan (32) | Feb (45) | Mar (68) | Apr (91) | May (38) | Jun (50) | Jul (83) | Aug (52) | Sep (108) | Oct (84) | Nov (125) | Dec (99) | 
| 2009 | Jan (166) | Feb (188) | Mar (129) | Apr (88) | May (88) | Jun (117) | Jul (112) | Aug (82) | Sep (32) | Oct (79) | Nov (68) | Dec (71) | 
| 2010 | Jan (49) | Feb (65) | Mar (113) | Apr (63) | May (71) | Jun (107) | Jul (59) | Aug (113) | Sep (103) | Oct (86) | Nov (132) | Dec (144) | 
| 2011 | Jan (124) | Feb (67) | Mar (114) | Apr (134) | May (81) | Jun (120) | Jul (137) | Aug (83) | Sep (143) | Oct (165) | Nov (288) | Dec (137) | 
| 2012 | Jan (337) | Feb (135) | Mar (159) | Apr (278) | May (358) | Jun (110) | Jul (77) | Aug (522) | Sep (301) | Oct (312) | Nov (319) | Dec (344) | 
| 2013 | Jan (216) | Feb (318) | Mar (196) | Apr (61) | May (369) | Jun (387) | Jul (338) | Aug (308) | Sep (247) | Oct (168) | Nov (335) | Dec (347) | 
| 2014 | Jan (322) | Feb (157) | Mar (414) | Apr (244) | May (152) | Jun (189) | Jul (152) | Aug (138) | Sep (108) | Oct (113) | Nov (65) | Dec (60) | 
| 2015 | Jan (97) | Feb (65) | Mar (109) | Apr (132) | May (153) | Jun (103) | Jul (117) | Aug (186) | Sep (113) | Oct (143) | Nov (115) | Dec (221) | 
| 2016 | Jan (157) | Feb (113) | Mar (145) | Apr (10) | May (95) | Jun (93) | Jul (159) | Aug (53) | Sep (94) | Oct (213) | Nov (88) | Dec (112) | 
| 2017 | Jan (124) | Feb (59) | Mar (82) | Apr (101) | May (27) | Jun (78) | Jul (144) | Aug (52) | Sep (48) | Oct (35) | Nov (63) | Dec (43) | 
| 2018 | Jan (38) | Feb (26) | Mar (63) | Apr (21) | May (75) | Jun (70) | Jul (72) | Aug (41) | Sep (84) | Oct (102) | Nov (28) | Dec (60) | 
| 2019 | Jan (13) | Feb (92) | Mar (141) | Apr (25) | May (138) | Jun (95) | Jul (121) | Aug (75) | Sep (32) | Oct (43) | Nov (122) | Dec (64) | 
| 2020 | Jan (54) | Feb (84) | Mar (239) | Apr (492) | May (182) | Jun (139) | Jul (126) | Aug (165) | Sep (162) | Oct (74) | Nov (108) | Dec (12) | 
| 2021 | Jan (59) | Feb (61) | Mar (22) | Apr (129) | May (97) | Jun (108) | Jul (96) | Aug (59) | Sep (36) | Oct (105) | Nov (46) | Dec (17) | 
| 2022 | Jan (67) | Feb (111) | Mar (104) | Apr (168) | May (58) | Jun (172) | Jul (118) | Aug (114) | Sep (177) | Oct (66) | Nov (208) | Dec (196) | 
| 2023 | Jan (99) | Feb (47) | Mar (53) | Apr (93) | May (70) | Jun (33) | Jul (45) | Aug (54) | Sep (89) | Oct (127) | Nov (41) | Dec (102) | 
| 2024 | Jan (38) | Feb (53) | Mar (78) | Apr (25) | May (26) | Jun (21) | Jul (56) | Aug (10) | Sep (65) | Oct (45) | Nov (38) | Dec (37) | 
| 2025 | Jan (78) | Feb (17) | Mar (47) | Apr (45) | May (6) | Jun (33) | Jul (68) | Aug (49) | Sep (28) | Oct (69) | Nov | Dec | 
| 
      
      
      From: Bertho S. <lc...@va...> - 2025-10-31 19:19:19
      
     | 
| On 10/29/25 12:34 AM, andy pugh wrote: > There are three things that I would like to see in 2.10, only one of > which is likely to be uncontentious.[snip] I think the HAL name length should be increased from the current 47 to something more substantial, like 127 or 255. I've run into and over the limit several times. And, running over the limit can cause some interesting crashes where you would not expect it (and hard to debug). Sure, the length checks should have been there everywhere, but they are not. The error tests and controls are apparently too lax. That also invites the thought that many components need to be updated to perform proper and consistent error checking, through and through. Possible errors at module load/init time are not always handled or handled properly. While we're at it, the shared mem size could also be upped (maybe to 48M or 64M) as there are no longer real issues with physical memory pressure anyway. The data sets have also become larger with the transition to 64-bit systems. -- Greetings Bertho (disclaimers are disclaimed) | 
| 
      
      
      From: Jon E. <el...@pi...> - 2025-10-30 15:52:09
      
     | 
| On 10/29/25 12:33, andy pugh wrote: > On Wed, 29 Oct 2025 at 17:00, Jon Elson <el...@pi...> wrote: > >> Yes, this is what I'm concerned about. How does a negative >> signed 32-bit value get converted to 64-bit? There are >> 32-bit encoder counts > There won't be when I have finished. > At least not inside LinuxCNC drivers. > There may be 32-bit input sources, but I am not aware of any. ppmc > appears to sign-extend 24 bits to 32. That will be expanded to 64. > There are 16-bit input sources (Modbus and Smart-serial for example) > but those are already sign-extended (and in many cases are _already_ > internally 64-bit) Specifically in my ppmc encoder driver section, I remember some fancy footwork looking at the sign of the 24-bit values and the sign and next bit of the 32-bit extension, to decide when a rollover is required. This took some hard thinking and testing to get right. Jon | 
| 
      
      
      From: Nicklas SB K. <nk...@nk...> - 2025-10-29 20:45:42
      
     | 
| Have looked on the general serial kinematics module and it seems the jacobian is calculated but never used. Also started to read thru the code for the trajoctory planner. Got the impression the trajectory planner does not handle velocity constraints for joints velocities or accelerations properly? If this is the case. Anyone know if someone started a branch for this? Any other documents like for example scientific articles or similar on the topic? Regards Nicklas Karlsson | 
| 
      
      
      From: rodw <ro...@ve...> - 2025-10-29 18:05:49
      
     | 
| Ref: https://linuxcnc.org/docs/stable/html/config/ini-config.html#sub:ini:sec:traj TPMOD = alternate_trajectory_planning module [tp_parms=value] The TPMOD variable is optional. If specified, use a specified (user-built) module instead of the default (tpmod). Module parameters (tp_parms) may be included if supported by the named module. The setting may be overridden from the command line using the -t option ($ linuxcnc -h). Its very easy to modify the build system to include an extra folder. Rod On 2025-10-29 22:11, andy pugh <bod...@gm...> wrote: > On Wed, 29 Oct 2025 at 07:57, rodw <ro...@ve...> wrote: > > > > Given the TP is supposed to be a stand alone module, why don't you deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and allow users to experiment with it on real hardware by changing their ini file settings? > > Are you sure this is the case? Which INI file setting? | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-29 17:34:31
      
     | 
| On Wed, 29 Oct 2025 at 17:00, Jon Elson <el...@pi...> wrote: > Yes, this is what I'm concerned about. How does a negative > signed 32-bit value get converted to 64-bit? There are > 32-bit encoder counts There won't be when I have finished. At least not inside LinuxCNC drivers. There may be 32-bit input sources, but I am not aware of any. ppmc appears to sign-extend 24 bits to 32. That will be expanded to 64. There are 16-bit input sources (Modbus and Smart-serial for example) but those are already sign-extended (and in many cases are _already_ internally 64-bit) (in fact in smart-serial there can be 8-bit encoder counter values extended to 64) -- 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 | 
| 
      
      
      From: Peter W. <pc...@me...> - 2025-10-29 17:20:58
      
     | 
| On Wed, 29 Oct 2025, Robert Schöftner wrote:
> Date: Wed, 29 Oct 2025 17:46:45 +0100
> From: "Robert [ISO-8859-1] Schöftner" <rm...@un...>
> Reply-To: EMC developers <emc...@li...>
> To: emc...@li...
> Subject: Re: [Emc-developers] 2.10 Proposals
> 
> Am Mittwoch, dem 29.10.2025 um 09:17 -0700 schrieb Peter Wallace:
>>
>> Yes, many components/drivers have parameters rather than pins for
>> this reason.
>>
>> In many cases, parameters are not expected to change at run time and
>> if
>> changed may cause issues.
>>
>>
>
> Even now you can change parameters at runtime ("setp" in halcmd)
>
> It's not like the concept of a parameter will be removed. It is a HAL-
> internal change that will allow the code to get rid of a bunch of
> pin/parameter checks und duplicated slightly different code.
>
> rene_dev could probably tell a bit more...
>
As long as its just internal changes, but changing the external hal pin type 
removes a way of indicating statics which are used in many components and 
drivers.
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
Peter Wallace
Mesa Electronics
 | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-29 17:14:26
      
     | 
| On Wed, 29 Oct 2025 at 16:03, Bertho Stultiens <lc...@va...> wrote: > > On 10/29/25 12:34 AM, andy pugh wrote: > > 1) Convert all int HAL pins to 64-bit. > > This will need *a lot* of work because code written for 32-bit uses > tricks and whatnot that are not necessarily compatible with 64-bit. > ...Each instance must be > found and properly re-coded for 64-bit. Indeed, and this is why it is taking so long. However, in most cases any internal 32-bit value can remain 32-bits, and will just get written to a 64-bit HAL pin. The reason to push for this is _precisely_ because we have instances of values being truncated (think high count and high speed encoders) Rather than allow 64-bit pins for these (done), and add conversion functions to downconvert to 32 bits, (done) _Then_ decide which other components might be fed this (possibly truncated value) it make more sense to silently convert all HAL pins to the larger types. -- 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 | 
| 
      
      
      From: Jon E. <el...@pi...> - 2025-10-29 16:57:37
      
     | 
| On 10/29/25 11:00, Bertho Stultiens wrote: > On 10/29/25 12:34 AM, andy pugh wrote: >> 1) Convert all int HAL pins to 64-bit. > > This will need *a lot* of work because code written for > 32-bit uses tricks and whatnot that are not necessarily > compatible with 64-bit. Each and every driver needs to be > checked, line for line, that it will work without problems > and as advertised. Especially tricky are expected implicit > truncation in 32-bit word operations. Each instance must > be found and properly re-coded for 64-bit. Yes, this is what I'm concerned about. How does a negative signed 32-bit value get converted to 64-bit? There are 32-bit encoder counts that are signed and can go negative. You need to know whether to sign extend it or just pad with high-order zeroes. Jon | 
| 
      
      
      From: Robert S. <rm...@un...> - 2025-10-29 16:46:58
      
     | 
| Am Mittwoch, dem 29.10.2025 um 09:17 -0700 schrieb Peter Wallace:
> 
> Yes, many components/drivers have parameters rather than pins for
> this reason.
> 
> In many cases, parameters are not expected to change at run time and
> if 
> changed may cause issues.
> 
> 
Even now you can change parameters at runtime ("setp" in halcmd)
It's not like the concept of a parameter will be removed. It is a HAL-
internal change that will allow the code to get rid of a bunch of
pin/parameter checks und duplicated slightly different code.
rene_dev could probably tell a bit more...
 | 
| 
      
      
      From: Robert S. <rm...@un...> - 2025-10-29 16:32:52
      
     | 
| Am Mittwoch, dem 29.10.2025 um 17:00 +0100 schrieb Bertho Stultiens: > On 10/29/25 12:34 AM, andy pugh wrote: > > 1) Convert all int HAL pins to 64-bit. > > This will need *a lot* of work because code written for 32-bit uses > tricks and whatnot that are not necessarily compatible with 64-bit. > Each > and every driver needs to be checked, line for line, that it will > work > without problems and as advertised. Especially tricky are expected > implicit truncation in 32-bit word operations. Each instance must be > found and properly re-coded for 64-bit. I don't think that there actually is that much code that relies on such behaviour, see the comment from andy regarding usage of "signed/unsigned". And IMHO relying on undefined behaviour (in the C/C++ language lawyer sense) like signed overflow is a bug that needs to be fixed, because sooner or later, some new compiler with additional "insights" into the code will optimize away such code (or stuff that depends on the undefined result). > > > 2) Do away with HAL parameters. Convert them all to full pins. > > Even though (most) parameters are located in shared memory, there is > a > real difference between pin and parameter access. Pins are always > indirect variables (must be dereferenced) in the HAL component, > whereas > parameters are direct variables. Converting parameters into pins adds > an > indirection and doubles the amount of shared memory accesses for any > operation. > in one typical 1kHz servo period we have O(millions) intructions on contemporary CPUs, even on "small" ones like arm cortex-Axx like in RPIs. a few hundred additional cycles won't affect anything. The problem is if some code misses to reserve memory for the parameters, that situation may be tricky to debug. and to be clear, both changes will be "internal", so not even writers of drivers / components will notice very much if anything at all. | 
| 
      
      
      From: Robert S. <rm...@un...> - 2025-10-29 16:28:27
      
     | 
| Am Mittwoch, dem 29.10.2025 um 17:03 +0100 schrieb nk...@nk...: > > Have to disagree to make all hal pins the same type. Type checking is > general something good then possible. This is a step in opposite > direction. > > Nicklas Karlsson type checking won't be removed. | 
| 
      
      
      From: Robert S. <rm...@un...> - 2025-10-29 16:26:14
      
     | 
| Am Mittwoch, dem 29.10.2025 um 10:43 -0500 schrieb Jon Elson: > On 10/28/25 18:34, andy pugh wrote: > > There are three things that I would like to see in 2.10, only one > > of > > which is likely to be uncontentious. > > > > 1) Convert all int HAL pins to 64-bit. > > This has to go in 2.10, if it happens at all. > Would this require all drivers to be rewritten? no | 
| 
      
      
      From: Peter W. <pc...@me...> - 2025-10-29 16:18:00
      
     | 
| On Wed, 29 Oct 2025, Bertho Stultiens wrote: > Date: Wed, 29 Oct 2025 17:10:48 +0100 > From: Bertho Stultiens <lc...@va...> > Reply-To: EMC developers <emc...@li...> > To: emc...@li... > Subject: Re: [Emc-developers] 2.10 Proposals > > On 10/29/25 5:03 PM, nk...@nk... wrote: >> Have to disagree to make all hal pins the same type. Type checking >> is general something good then possible. This is a step in opposite >> direction. > Agree. > > Also, my view has always been that pins are dynamic data and parameters are > (run-time static) configuration. That would make separation a Good Thing(TM). > > -- > Greetings Bertho > > (disclaimers are disclaimed) > Yes, many components/drivers have parameters rather than pins for this reason. In many cases, parameters are not expected to change at run time and if changed may cause issues. > Peter Wallace Mesa Electronics | 
| 
      
      
      From: Bertho S. <lc...@va...> - 2025-10-29 16:11:02
      
     | 
| On 10/29/25 5:03 PM, nk...@nk... wrote: > Have to disagree to make all hal pins the same type. Type checking > is general something good then possible. This is a step in opposite > direction. Agree. Also, my view has always been that pins are dynamic data and parameters are (run-time static) configuration. That would make separation a Good Thing(TM). -- Greetings Bertho (disclaimers are disclaimed) | 
| 
      
      
      From: <nk...@nk...> - 2025-10-29 16:03:13
      
     | 
| Have to disagree to make all hal pins the same type. Type checking is general something good then possible. This is a step in opposite direction. Nicklas Karlsson Den Onsdag, Oktober 29, 2025 16:43 CET, skrev Jon Elson <el...@pi...>: On 10/28/25 18:34, andy pugh wrote: > There are three things that I would like to see in 2.10, only one of > which is likely to be uncontentious. > > 1) Convert all int HAL pins to 64-bit. > This has to go in 2.10, if it happens at all. Would this require all drivers to be rewritten? > > 2) Do away with HAL parameters. Convert them all to full pins. > In theory using parameters saves HAL shared memory as they are > meant to live in normal memory. In practice > nearly every HAL component puts both pins and parameters in HAL > shared memory, so this advantage is > not realised. René has a branch in which this has been done. I have no complaint about this one. > 3) Incorporate the 9-axis blending TP from Tormach Pathpilot. > I have the code, and have even tried just dropping it in. > https://github.com/LinuxCNC/linuxcnc/compare/master...Tormach_9_axis > It's obviously not going to work like that. If anyone wants to > look at making it all work, that would be great :-) > That PR serves the purpose of showing what has changed and where. > I don't know if it's a good place to > start actually merging though. This could be a can of worms, and require some rigorous testing, but sounds like a good idea! Jon _______________________________________________ Emc-developers mailing list Emc...@li... https://lists.sourceforge.net/lists/listinfo/emc-developers | 
| 
      
      
      From: Bertho S. <lc...@va...> - 2025-10-29 16:00:16
      
     | 
| On 10/29/25 12:34 AM, andy pugh wrote: > 1) Convert all int HAL pins to 64-bit. This will need *a lot* of work because code written for 32-bit uses tricks and whatnot that are not necessarily compatible with 64-bit. Each and every driver needs to be checked, line for line, that it will work without problems and as advertised. Especially tricky are expected implicit truncation in 32-bit word operations. Each instance must be found and properly re-coded for 64-bit. > 2) Do away with HAL parameters. Convert them all to full pins. Even though (most) parameters are located in shared memory, there is a real difference between pin and parameter access. Pins are always indirect variables (must be dereferenced) in the HAL component, whereas parameters are direct variables. Converting parameters into pins adds an indirection and doubles the amount of shared memory accesses for any operation. -- Greetings Bertho (disclaimers are disclaimed) | 
| 
      
      
      From: Jon E. <el...@pi...> - 2025-10-29 15:43:59
      
     | 
| On 10/28/25 18:34, andy pugh wrote: > There are three things that I would like to see in 2.10, only one of > which is likely to be uncontentious. > > 1) Convert all int HAL pins to 64-bit. > This has to go in 2.10, if it happens at all. Would this require all drivers to be rewritten? > > 2) Do away with HAL parameters. Convert them all to full pins. > In theory using parameters saves HAL shared memory as they are > meant to live in normal memory. In practice > nearly every HAL component puts both pins and parameters in HAL > shared memory, so this advantage is > not realised. René has a branch in which this has been done. I have no complaint about this one. > 3) Incorporate the 9-axis blending TP from Tormach Pathpilot. > I have the code, and have even tried just dropping it in. > https://github.com/LinuxCNC/linuxcnc/compare/master...Tormach_9_axis > It's obviously not going to work like that. If anyone wants to > look at making it all work, that would be great :-) > That PR serves the purpose of showing what has changed and where. > I don't know if it's a good place to > start actually merging though. This could be a can of worms, and require some rigorous testing, but sounds like a good idea! Jon | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-29 15:31:19
      
     | 
| On Wed, 29 Oct 2025 at 15:06, Robert Schöftner <rm...@un...> wrote: > https://www.linuxcnc.org/docs/devel/html/man/man9/tpcomp.9.html > > not sure if there actually is a pluggable trajectory planner. OK, that looks like it could be helpful. Though the Tormach code predates the introduction of pluggable TPs (I think) -- 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 | 
| 
      
      
      From: Robert S. <rm...@un...> - 2025-10-29 15:02:26
      
     | 
| Am Mittwoch, dem 29.10.2025 um 12:10 +0000 schrieb andy pugh: > On Wed, 29 Oct 2025 at 07:57, rodw <ro...@ve...> wrote: > > > > Given the TP is supposed to be a stand alone module, why don't you > > deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and > > allow users to experiment with it on real hardware by changing > > their ini file settings? > > Are you sure this is the case? Which INI file setting? > https://www.linuxcnc.org/docs/devel/html/man/man9/tpcomp.9.html not sure if there actually is a pluggable trajectory planner. | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-29 12:10:47
      
     | 
| On Wed, 29 Oct 2025 at 07:57, rodw <ro...@ve...> wrote: > > Given the TP is supposed to be a stand alone module, why don't you deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and allow users to experiment with it on real hardware by changing their ini file settings? Are you sure this is the case? Which INI file setting? -- 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 | 
| 
      
      
      From: rodw <ro...@ve...> - 2025-10-29 07:55:20
      
     | 
| Given the TP is supposed to be a stand alone module, why don't you deploy the Tormach planner (lets call it TTP) to /src/emc/ttp and allow users to experiment with it on real hardware by changing their ini file settings? If it works out before the release of 2.10, you could optionally retire the existing TP in 2.10 or in 2.11 Rod On 2025-10-29 17:01, Robert Schöftner <rm...@un...> wrote: > Am Dienstag, dem 28.10.2025 um 23:34 +0000 schrieb andy pugh: > > 2) Do away with HAL parameters. Convert them all to full pins. > > In theory using parameters saves HAL shared memory as they are > > meant to live in normal memory. In practice > > nearly every HAL component puts both pins and parameters in HAL > > shared memory, so this advantage is > > not realised. René has a branch in which this has been done. > > Maybe it made sense in the 90ies with single core PCs with 16-ish MB > RAM to limit unwappable memory-locked shared memory. OTOH even then, a > CNC controller that runs into swap was a bad idea. > > Nowadays with low-end systems being 4-core 16GB RAM machines, i.e. 1000 > times the RAM and on-cpu caches as big as all memory of the 90ies > machines, the need to conserve shared memory is not that pressing any > more. > > > I tested that branch in July but couldn't yet get it to work on real > hardware (and then ran out of spare time). Implementation details of > HAL pins make this change somewhat tricky. Converted code needs to > allocate memory for the parameters, if such allocation is missing, some > strange behaviour and crashes in the realtime part will result that are > hard to debug. It seems to work in sim, completes the tests IIRC, but > that branch needs testing on real hardware. > > > -- > Robert Schöftner <rm...@un...> > > > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers | 
| 
      
      
      From: Robert S. <rm...@un...> - 2025-10-29 07:01:11
      
     | 
| Am Dienstag, dem 28.10.2025 um 23:34 +0000 schrieb andy pugh: > 2) Do away with HAL parameters. Convert them all to full pins. > In theory using parameters saves HAL shared memory as they are > meant to live in normal memory. In practice > nearly every HAL component puts both pins and parameters in HAL > shared memory, so this advantage is > not realised. René has a branch in which this has been done. Maybe it made sense in the 90ies with single core PCs with 16-ish MB RAM to limit unwappable memory-locked shared memory. OTOH even then, a CNC controller that runs into swap was a bad idea. Nowadays with low-end systems being 4-core 16GB RAM machines, i.e. 1000 times the RAM and on-cpu caches as big as all memory of the 90ies machines, the need to conserve shared memory is not that pressing any more. I tested that branch in July but couldn't yet get it to work on real hardware (and then ran out of spare time). Implementation details of HAL pins make this change somewhat tricky. Converted code needs to allocate memory for the parameters, if such allocation is missing, some strange behaviour and crashes in the realtime part will result that are hard to debug. It seems to work in sim, completes the tests IIRC, but that branch needs testing on real hardware. -- Robert Schöftner <rm...@un...> | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-28 23:35:14
      
     | 
| There are three things that I would like to see in 2.10, only one of
which is likely to be uncontentious.
1) Convert all int HAL pins to 64-bit.
    This has to go in 2.10, if it happens at all. Master currently
supports both 64-bit and 32-bit int HAL pins. Once
    that is released I believe it is too late to wind it back.
    If it is done now it ought to be almost invisible, and all
existing HAL files should still work.
    Initially the hal_pin_new_s32 and u32 function calls will be
retained, but will create 64-bit pins, and warn that
    hal_pin_signed / unsigned should now be used.
    In a development branch all .comp files in-tree have been updated
(.comp always did say to use signed/unsigned.
    I think jeper foresaw this.)
    One fly in the ointment is Gladevcp (and possibly other VCPs)
which specifically name the pins as _u32 / _s32.
    These would simply become 64-bit, and would still join the hal
nets, but can't have their names changed as this
    would break existing HAL files UNLESS the update-ini script is
expanded to change the pin names in HAL files.
    (Some of this has already been done:
https://github.com/LinuxCNC/linuxcnc/blob/andypugh/long_hal_ints/src/emc/ini/update_ini.py#L553)
2) Do away with HAL parameters. Convert them all to full pins.
    In theory using  parameters saves HAL shared memory as they are
meant to live in normal memory. In practice
    nearly every HAL component puts both pins and parameters in HAL
shared memory, so this advantage is
   not realised. René has a branch in which this has been done.
3) Incorporate the 9-axis blending TP from Tormach Pathpilot.
    I have the code, and have even tried just dropping it in.
    https://github.com/LinuxCNC/linuxcnc/compare/master...Tormach_9_axis
    It's obviously not going to work like that. If anyone wants to
look at making it all work, that would be great :-)
    That PR serves the purpose of showing what has changed and where.
I don't know if it's a good place to
    start actually merging though.
-- 
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
 | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-28 00:26:06
      
     | 
| On Mon, 27 Oct 2025 at 23:49, rodw <ro...@ve...> wrote: > > > Does the Linuxcnc ISO work? It should cos the Debian version is a pre release and it was getting 2.9.4. I'll try on a VM tonight I have just updated the script to require that it be run with sudo, and taken the explicit "sudos" out of the script. This seems cleaner. It's on the server under the same name: www.linuxcnc.org/linuxcnc-install-test.sh -- 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 | 
| 
      
      
      From: andy p. <bod...@gm...> - 2025-10-28 00:12:19
      
     | 
| On Mon, 27 Oct 2025 at 23:49, rodw <ro...@ve...> wrote: > > Does the Linuxcnc ISO work? It should cos the Debian version is a pre release and it was getting 2.9.4. I'll try on a VM tonight Anything installed from the ISO should be fine, it should have the keys and suchlike already installed. (note that Trixie needs a new key, let me push that) https://github.com/LinuxCNC/linuxcnc-live-build/tree/trixie I built that 2.9.6 Trixie ISO using that config, but I haven't published it as it is flaky on my test PC (Asroc N100DC. But that is in some ways a flaky PC...) Also, I don't like how the splash screen appears in BIOS mode but not in UEFI. (and I dislike even more that I don't know why) Back to the subject, the installer script is only intended for pre-installed Debian systems. (it adds our Apt archive and signing key, updates apt and installs the relevant 2.9-uspace for the OS) -- 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 |