Re: [Emc-developers] State Tags and Hal_port pins

[Gene Heskett]

On Saturday 16 May 2020 02:01:41 Rod Webster wrote:

> Now we have both State tags and the hal_port pin type in master
> branch, it occurred to me that it might be possible to publish the
> state tags structure to a hal_port pin and a component could check
> motion.motion_type or the tag type to determine the data contained in
> hal_port.
>
> A cursory read indicated that different classes of tags had different
> structures.
>
> I'm particularly interested in being able to retrieve the arc radius
> when the current segment is an arc.
>
> Is this feasible? Could  somebody explain how to go about doing
> something like this?
>
> If we could pull this off, it would allow easy access to the state
> tags from a custom component instead of letting state tags sulk in the
> EMC folder.
>
> Any help and advice would be appreciated.
>
We've had some parts of that for a while, Rod. I have a bit of hal that 
looks at motions state, and if not =5, disables response to a probe 
input, so I can use that same wire for a home switch. I've since put a 
5i25 and another bob in that machine, but that code is still there.

Nice to see this added. It expands what hal can do.
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> VMN®
> www.vmn.com.au
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-developers] State Tags and Hal_port pins

[Reinhard]

Hi Rod,

On Samstag, 16. Mai 2020, 08:01:41 CEST Rod Webster wrote:
> Now we have both State tags and the hal_port pin type in master branch, 
>... 
>, it would allow easy access to the state tags from a custom component
> instead of letting state tags sulk in the EMC folder.

don't know, if I got you right - to me it sounds as if you oppose the state 
tags.

>From my point of view, state tags are for communication with frontend / UI, 
whereas hal is the communication with hardware / drivers. 
So state tags are far from being complete. But I don't think, that they are 
equivalent or should be. No. There might be information, that will be 
important for the hardware-side and be of little interest for the frontend 
side.
I think, if NML is the communication portal of linuxcnc to other software, 
than an UI should not have to bother with hal. 
An UI may do that to give the users another taste of UI, but tools for hal 
exists and work, why reinvent the wheel?
So I appreciate state tags and would like them to become more complete to be 
able to offer all informations around machine state ...

May be, my point of view does not reflect the state of linuxcnc. 
But that's what I think and would like to become true one day :)


cheers Reinhard




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

[Emc-developers] State Tags and Hal_port pins

[Rod Webster]

Now we have both State tags and the hal_port pin type in master branch,
it occurred to me that it might be possible to publish the state tags
structure to a hal_port pin and a component could check motion.motion_type
or the tag type to determine the data contained in hal_port.

A cursory read indicated that different classes of tags had different
structures.

I'm particularly interested in being able to retrieve the arc radius
when the current segment is an arc.

Is this feasible? Could  somebody explain how to go about doing
something like this?

If we could pull this off, it would allow easy access to the state tags
from a custom component instead of letting state tags sulk in the EMC
folder.

Any help and advice would be appreciated.


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

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

Re: [Emc-developers] spindle status

[Gene Heskett]

On Friday 15 May 2020 14:39:12 Nicklas Karlsson wrote:

> > On Thursday 14 May 2020 14:57:59 Chris Morley wrote:
> > > Well I dare say that a VFD counts as hardware.
> > > I use serial data from my VFD for spindle RPM display.
> > >
> > > My point was though that to get actual RPM back to a gui you
> > > pretty much use HAL and can't use NML (currently anyways).
> > >
> > > Chris
> >
> > Unfortunately, the vfd's I have bought are totally w/o even the
> > footprint for a serial port on the pcb's.  And yes, I've looked.
>
> The motor have encoder or some other kind of rotational sensor?
>
Not that I have been able to find, so I have a fudged up drive to the 
tach, calibrated so wide open at 400 hertz is 24k. I think the motor is 
a hard armature version meaning that up till it slips and stops, its 
running synchronous. I finally found the low speed current controls, 
difficult in the poor chinglish manual and set them up for nameplate FLA 
at low speed and it now has phenomenal torque at 500 rpms and less.  I'm 
more than happy with that.

And just now I got a refund from the German motor mount maker that I was 
going use as a nema23 mount on the back of my BS-1 indexer, seems they 
can't ship to the US because of Covid19.  And thats the most compact 
mount I could find. Might have to make my own.  I did manage to get that 
BS-1 up onto the mills table today, but once I had done that, and 
verified my mill had power enough to move with that 80kg on its table, I 
found I can't rotate it but about 5 degrees with the cranks despite 
loosening the lock levers. No idea whats wrong. But I've finally got it 
up off the floor where I can work with it.


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

Re: [Emc-developers] spindle status

[Nicklas Karlsson]

> On Thursday 14 May 2020 14:57:59 Chris Morley wrote:
> 
> > Well I dare say that a VFD counts as hardware.
> > I use serial data from my VFD for spindle RPM display.
> >
> > My point was though that to get actual RPM back to a gui you pretty
> > much use HAL and can't use NML (currently anyways).
> >
> > Chris
> 
> Unfortunately, the vfd's I have bought are totally w/o even the footprint 
> for a serial port on the pcb's.  And yes, I've looked.

The motor have encoder or some other kind of rotational sensor?


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

Re: [Emc-developers] OpenCN forum + announcement of release v2

[Herzog Raoul]

dear Nicklas,

the problem you mentioned with cookies for accessing the OpenCN forum 
https://discourse.heig-vd.ch/c/opencn seems to be resolved.

best regards,

Raoul

-Message d'origine-
De : N  
Envoyé : mercredi 13 mai 2020 22:22
À : Herzog Raoul 
Objet : Re: [Emc-developers] OpenCN forum + announcement of release v2

I tried to register on the forum but failed, it made complaint about cookies 
but do not think this an issue because it works everyhere also then asked if 
cookies are OK.

Usually there are discussions of software steppers and statistical measurement 
of latency. This however look like they now what they are doing:
  4) remote GUI in order to eliminate intermittent jitter problems in EtherCAT 
@10 kHz due to DMA access of GPU


Have two different size Ethercat inverter card  there I am soldering on 
prototype board right now. Have already tested first prototype boards and they 
should exactly what is needed for CNC machine servo drives but nothing special. 
Would probably make sense to make them available under GNU license, then I 
could probably get some help with control algorithms for different motors while 
others would benifit from them.

Regards Nicklas Karlsson


> dear Reinhard, dear LinuxCNC developers,
> 
> 
> 
> I refer to the last phrase of Reinhard's email below.
> 
> 
> 
> We installed a forum for all questions related to OpenCN :
> 
> https://discourse.heig-vd.ch/c/opencn
> 
> You are welcome to input all issues, installation problems, etc.
> 
> 
> 
> Unfortunately we had to fork LinuxCNC because the real-time framework of 
> OpenCN differs a lot (Xenomai with asymmetric multi processing (AMP)).
> 
> 
> 
> We plan a release v2 of OpenCN by end of june 2020 with the following 
> features :
> 
> 
> 
> 1) Compressing of small G01 blocks by B-Splines
> 
> 2) Detection and handling of cusps in the trajectory, better handling 
> of feedrate near zero
> 
> 3) Linux 4.19 LTS
> 
> 4) remote GUI in order to eliminate intermittent jitter problems in 
> EtherCAT @10 kHz due to DMA access of GPU
> 
> 5) x86 and Raspberry Pi support
> 
> 6) bug removals and better stability
> 
> 
> 
> We are working hard and we'll keep you updated !
> 
> 
> 
> best regards,
> 
> 
> 
> Raoul
> 
> 
> 
> 
> 
> -Message d'origine-
> De : Reinhard  Envoyé : lundi 4 mai 
> 2020 16:09 À : EMC developers 
> Objet : Re: [Emc-developers] Third-Party GUIs
> 
> 
> 
> On Montag, 4. Mai 2020, 13:43:53 CEST andy pugh wrote:
> 
> > I do think that MK perhaps got too caught-up in fixing the archaic 
> > and
> 
> > weird LinuxCNC software architecture rather than considering the
> 
> > question:
> 
> > "How does this make the software make better parts"
> 
> 
> 
> Yes, Andy - that's exactly what I thought, when I tried out machinekit.
> 
> 
> 
> When I read in the forum, that machinekit does so many things better than 
> linuxcnc, I started to scratch for machinekit.
> 
> There's a lot to read about what is bad in linuxcnc and you can read a lot of 
> propaganda, what machinekit wants to make different ...
> 
> But you can read next to nothing about what machinekit already has done.
> 
> 
> 
> From all the proposals, I agreed in may be one or tho points, but when I 
> installed machinekit, I got disappointed a lot.
> 
> 
> 
> Frontend is axis and while axis from linuxcnc ships with an intelligent 
> sample, where you can learn a lot about coding GCode for linuxcnc, machinekit 
> provides a dumb cam-output.
> 
> Axis works the same as in linuxcnc, so as a user I can't see any benefit.
> 
> 
> 
> Same is true for the youtube-lessons, which covered only trivial points, that 
> every programmer should know, who dedicates itself to cnc ...
> 
> For me - just wasting my time :(
> 
> 
> 
> > And that is the danger, LinuxCNC is a machine controller. There is
> 
> > limited value to the user-base in making large changes to the
> 
> > underlying software implementation that they never see.
> 
> 
> 
> Sure - I believe, if architecture gets cleaned up, the goal should be users 
> benefit in the sense of working out existing issues. Some issues seem to be 
> impossible to solve with current architecture.
> 
> So that's the staff gauge.
> 
> 
> 
> I feel so sad about opencn - they seem to have reached real improvements. But 
> they did a fork, which is not usable with the provided instructions.
> 
> That improvement could have enriched linuxcnc - and now it looks like it will 
> get lost.
> 
> 
> 
> 
> 
> cheers Reinhard
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 
> Emc-developers mailing list
> 
> Emc-developers@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


___
Emc-developers mailing list
Emc-developers@lists.s

Re: [Emc-developers] RTAI Testing

[andy pugh]

On Fri, 15 May 2020 at 00:27, andy pugh  wrote:

> > I am going to halt that test and run the Seb abs.0 test with
> > RTAI-uspace to see if that is different to RTAI-kernel. (ie
> > LXRT-realtime not RTAI-realtime)
>
> Which got to 10,000 cycles, but then the kernel-mode RTAI test often does.
> I will leave it overnight.

Failed at 12,877 cycles after slightly more than 12 hours running.
(the LXRT-realtime test seems to take rather longer to start)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912


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

Re: [Emc-developers] spindle status

[Reinhard]

Hi Chris,

thanks again for the trigger. I don't know, what happened ...

> As soon as I start a program with halaccess without the help of halcmd, it
> crashes. And I have no idea why. 

I stil don't have any idea - but same crashing code now works without 
problems. Just recompiled it. What Surprise!
May be I was trapped by my dying pc?

Any way - whoohoo - hal: here I come ;)


cheers Reinhard




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