hello again, well ive eliminated the lovejoys was able to get good scalind at .1 and .5 but not both with the same numbers, I gave up on the microstepping and just fudged the gear ratio. However I just dont seem to be able to get consistent scaling. Are there drives that just dont work w/ linuxcnc? should i try another computer? how do i know if its loosing steps aside from the obvious noise? is it possible to lose steps and not know it? could not enough power supply voltage cause missed steps? im running one 24 v supply with 2 3,8 amp 1600 oz motors(havent hooked z up yet as i need x/y to make the mount for z. If there is someplace else i should look for answers? I havent been able to get on the irc for about4 months so ???????
On Tue, Jun 26, 2012 at 1:42 AM, < [email protected]> wrote: > Send Emc-developers mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/emc-developers > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emc-developers digest..." > > > Today's Topics: > > 1. Re: RFC: HAL as a filesystem - useful? (Michael Haberler) > 2. Re: Emc-developers Digest, Vol 74, Issue 14 (jeremy youngs) > 3. Re: Emc-developers Digest, Vol 74, Issue 14 (andy pugh) > 4. Re: RFC: HAL as a filesystem - useful? (Joachim Franek) > 5. Re: RFC: HAL as a filesystem - useful? (Michael Haberler) > 6. Re: RFC: HAL as a filesystem - useful? (Michael Haberler) > 7. Re: RFC: HAL as a filesystem - useful? (EBo) > 8. Re: RFC: HAL as a filesystem - useful? (Michael Haberler) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Jun 2012 16:26:45 +0200 > From: Michael Haberler <[email protected]> > Subject: Re: [Emc-developers] RFC: HAL as a filesystem - useful? > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Am 25.06.2012 um 15:42 schrieb Joachim Franek: > > > On Monday 25 June 2012 13:11:55 Michael Haberler wrote: > >> I'm a bit unsure about a decent use case and from understanding fuse > (accomplished) to a useful tool (not accomplished) it's quite a bit of work > >> however now that halrmt is gone, remote access to HAL has an option > less; > >> but whether remote file access through, say, samba, is a usable > realtime monitoring method is TBD; I guess no due to caching. > >> > > I think it is usefull for transfering data from userspace > > to hal. For example I can readout my UT70D (a dmm) > > over RS232 and a simple > > write(file,dmm_value); > > transfers the value to hal space. > > I would guess the more direct way to do this is a Python userland HAL > component (http://www.linuxcnc.org/docs/devel/html/hal/halmodule.html) > > - use pyserial to access the port > - suffer through decoding the protocol ( > http://www-user.tu-chemnitz.de/~heha/hs_freeware/UNI-T/ might help) > - update hal pins with results > > -m > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 25 Jun 2012 11:35:51 -0400 > From: jeremy youngs <[email protected]> > Subject: Re: [Emc-developers] Emc-developers Digest, Vol 74, Issue 14 > To: [email protected] > Message-ID: > <CA+Mq1eQ+CUwLxYXrN1eN24RzRbh=_hdqgekbghjb7j+wot-...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > With good reason. Microsteps can only ever be an integer, and is > normally a power of 2 as well. > > > so andy if i get this right microstep will be 1, 2, 4, 6, 8 ? also is there > a way to make it run one step to measure that output at the axis? also my > drives will handle up to 80v so im going to try 48 and see what happens, > will making that upgrade increase the rate I can step at thanx > > > ------------------------------ > > Message: 3 > Date: Mon, 25 Jun 2012 16:48:43 +0100 > From: andy pugh <[email protected]> > Subject: Re: [Emc-developers] Emc-developers Digest, Vol 74, Issue 14 > To: EMC developers <[email protected]> > Message-ID: > <CAN1+YZUuK4BXu6LeqZHG8jg3Ou9sWR89=MKY2HrWJ=yxc2f...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On 25 June 2012 16:35, jeremy youngs <[email protected]> wrote: > > so andy if i get this right microstep will be 1, 2, 4, 6, 8 ? > > Yes, and it will be a setting in the stepper drive (or a fixed value). > > it is worth knowing that Stepconf just multiplies together the > microstep, leadscrew pitch and pully diameters to come up with one > single number. So putting a fudge-factor in the microsteps box will > have the desired effect, just in a rather odd way. > > > im going to try 48 and see what happens, > > will making that upgrade increase the rate I can step at thanx > > That depends what is currently limiting your step rate. If the motors > run out of torque and stall, then yes. If you are reaching the limit > of software step generation, then no. > > -- > atp > If you can't fix it, you don't own it. > http://www.ifixit.com/Manifesto > > > > ------------------------------ > > Message: 4 > Date: Mon, 25 Jun 2012 17:56:18 +0200 > From: Joachim Franek <[email protected]> > Subject: Re: [Emc-developers] RFC: HAL as a filesystem - useful? > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: Text/Plain; charset="iso-8859-1" > > On Monday 25 June 2012 16:26:45 Michael Haberler wrote: > > I would guess the more direct way to do this is a Python userland HAL > component (http://www.linuxcnc.org/docs/devel/html/hal/halmodule.html) > > > > - use pyserial to access the port > > - suffer through decoding the protocol ( > http://www-user.tu-chemnitz.de/~heha/hs_freeware/UNI-T/ might help) > > - update hal pins with results > > Thanks for the hint. > Is there a plain c equivalent for > "import hal" ? > > Joachim > > > > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Jun 2012 18:03:51 +0200 > From: Michael Haberler <[email protected]> > Subject: Re: [Emc-developers] RFC: HAL as a filesystem - useful? > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Am 25.06.2012 um 17:56 schrieb Joachim Franek: > > > On Monday 25 June 2012 16:26:45 Michael Haberler wrote: > >> I would guess the more direct way to do this is a Python userland HAL > component (http://www.linuxcnc.org/docs/devel/html/hal/halmodule.html) > >> > >> - use pyserial to access the port > >> - suffer through decoding the protocol ( > http://www-user.tu-chemnitz.de/~heha/hs_freeware/UNI-T/ might help) > >> - update hal pins with results > > > > Thanks for the hint. > > Is there a plain c equivalent for > > "import hal" ? > > yes, make it a userland (non-RT) .comp component > > see options: > > option userspace yes > option userinit yes > > http://www.linuxcnc.org/docs/devel/html/hal/comp.html > > > > > Joachim > > > > > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > ------------------------------ > > Message: 6 > Date: Mon, 25 Jun 2012 18:08:53 +0200 > From: Michael Haberler <[email protected]> > Subject: Re: [Emc-developers] RFC: HAL as a filesystem - useful? > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Am 25.06.2012 um 18:03 schrieb Michael Haberler: > >> > >> Thanks for the hint. > >> Is there a plain c equivalent for > >> "import hal" ? > > > > yes, make it a userland (non-RT) .comp component > > or if you shy comp, see the userland HAL components under > src/hal/user_comps - those dont use .comp but the hal C api > > -m > > > ------------------------------ > > Message: 7 > Date: Tue, 26 Jun 2012 00:34:15 -0400 > From: EBo <[email protected]> > Subject: Re: [Emc-developers] RFC: HAL as a filesystem - useful? > To: <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Also take a look at the p9fs/npfs/v9fs stuff that was recently brought > into the kernel main. There is a server for it available that looks > interesting. (see http://sourceforge.net/projects/npfs for a place to > start) > > On Mon, 25 Jun 2012 16:17:17 +0200, Michael Haberler wrote: > > Am 25.06.2012 um 15:13 schrieb andy pugh: > > > >> On 25 June 2012 12:11, Michael Haberler <[email protected]> wrote: > >>> I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did > >>> a prototype halfs which makes the HAL namespace visible in the Linux > >>> filesystem. > >>> components functions params pins signals threads > >> > >> I suspect that I might have been the trigger for this, so probably > >> ought to comment. > > > > well, not quite. > > > > Poked by your theme I investigated the options for having an > > associated char device in an RT component; the hard part is signaling > > - without busy wait - between the chardevice (linux kernel land) and > > the RT component (rtapi/rtai land) which are pretty much 'ships in > > the > > night'; this is possible but for the more difficult path > > (RT->chardevice signalling) this needs an RTAI function currently not > > covered by RTAPI ( rt_pend_linux_srq(), see > > > > > http://git.mah.priv.at/gitweb/kernel-playground.git/blob/0310dd00330a90a995e79993d404947798e241d4:/rt-comp-with-device/rtdev2.c > ) > > > >> What I was looking for was a way to access HAL realtime functions > >> from > >> Userspace. I think this could be part of that solution. > > > > that path (chardev->RT comp) is easier since the RT comp polls anyway > > - either the write, or ioctl dev methods can do this directly in > > linux > > kernel land, or by queuing a request such that is executed in the RT > > context on the next cycle. > > > > 'Calling a HAL function' directly from the kernel (say a write or > > ioctl method) basically would execute an RT function in a non-RT > > context; in particular the instance data pointer and timing values > > are > > missing. Not impossible but to be kept in mind. > > > > NB - this method assumes RTAI and RTAPI - the device wouldnt work as > > a userland HAL component. This might or might not be an issue > > (firmware upgrades in a simulator are kindof useless), but at least > > it's irregular. > > > >> Other use-cases: > >> Currently BSPI outputs the names of the BSPI instances to dmesg. > >> This > >> is not particularly convenient. Being able to find them in a file > >> tree > >> would be neater. > > > > since this is more like attribute retrieval, I'd guess sysfs would be > > the better solution; again, non-sim only but with a driver for real > > HW > > this is a non-issue as well > > > > I'm happy to add such an animal to a given RT comp as a proof of > > concept, provided someone helps me across the street how to retrieve > > which attributes > > > >> It might make the job of configuration tools such as PNCConf easier, > >> especially now that so many of the Mesa cards create their own pin > >> names. > > > > sysfs is real straightforward, but I'd appreciate a suggestion what > > makes sense to export > > > >> The original idea was that one might be able to pipe a firmware file > >> directly to a smart-serial remote card from userspace to somewhere > >> where kernel space could pick it up and use it. > > > > there's also a more linuxish way to grind this cat, the kernel > > firmware request infrastructure (see e.g. > > > > > http://stackoverflow.com/questions/950107/how-does-linux-kernel-know-where-to-look-for-driver-firmware > ) > > > > I agree that doing a UART-over-a-HAL-pin-to-send-files is a wart) > > > >> If there is no significant overhead I would be tempted to suggest > >> that > >> it be implemented and then we can see how useful it turns out to be. > > > > the halfuse thing is a user process, and uses the HAL userland API > > (plus some of the private API like halcmd does, but nothing else). In > > particular, it doesnt use RTAPI (except logging, but that isnt really > > needed). As such it isnt any help with the firmware loading theme. > > > > -m > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. > > Discussions > > will include endpoint security, mobile security and the latest in > > malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Emc-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > ------------------------------ > > Message: 8 > Date: Tue, 26 Jun 2012 07:42:07 +0200 > From: Michael Haberler <[email protected]> > Subject: Re: [Emc-developers] RFC: HAL as a filesystem - useful? > To: EMC developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > Am 26.06.2012 um 06:34 schrieb EBo: > > > Also take a look at the p9fs/npfs/v9fs stuff that was recently brought > > into the kernel main. There is a server for it available that looks > > interesting. (see http://sourceforge.net/projects/npfs for a place to > > start) > > I read into plan9 and Styx a bit, and am unsure what to make of it - what > do you have in mind? > > If the goal is to expose HAL objects in a local file system tree similar > like sysfs exposes kernel internals, I dont immediately see an advantage > for it over fuse; it's another means of injecting named objects into the fs > tree and hooking operations to them; I might be missing something > fundamental though > > It is conceivable to think about something completely different: a method > for local & remote object access which encompasses state access and > modification (HAL) as well RPC-style messaging (NML). There's something to > be said for a unified communications mechanism which supports runtime-named > objects, late binding and which is kernel compatible (NML is none of the > previous, leading to duplicity of mechanisms (e.g. halrmt vs emcrsh - why > 2?), debugging, translation issues like usrmotif.c etc). Having it exposed > in the filesystem would be a plus. I think remote operation is a valuable > asset even distribution of components has been a bit fallen by the wayside > in linuxcnc. > > To work remotely, it probably needs to look similar like a filesystem > protocol - bind a name to an object, operate on it etc. I'm not sure > whether all operations needed could be naturally funneled through existing > linux filesystem *operations*. The other issue is that userland gateways > like a fuse filesystem probably are real performance dogs (that can be > fixed, at the expense of extra kernel code though, at which point fuse aint > helpful). > > - Michael > > > > > > On Mon, 25 Jun 2012 16:17:17 +0200, Michael Haberler wrote: > >> Am 25.06.2012 um 15:13 schrieb andy pugh: > >> > >>> On 25 June 2012 12:11, Michael Haberler <[email protected]> wrote: > >>>> I wanted to learn about Fuse (http://fuse.sourceforge.net/) and did > >>>> a prototype halfs which makes the HAL nam > > > > ------------------------------ > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ------------------------------ > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > End of Emc-developers Digest, Vol 74, Issue 15 > ********************************************** > -- jeremy youngs ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
