Back
[00:13:39] <tomp2> jepler: dont bother to run that windows control pgm, i see its hard coded to an impossible address. and i dont have VB VC Delphi to re-write it.
[00:15:24] <SWPadnos> if you have the source, I can probably make a new exe for you
[00:23:59] <tomp2> SWPadnos: I'd like to try that, would you like VB VC or Delphi src?
[00:24:12] <tomp2> i think you'd just chg the address
[00:24:52] <tomp2> before i trash the 160$
[00:24:55] <SWPadnos> not sure. I have Borland C++ Builder 5. I'm pretty sure it compiles some Delphi code correctly, but I'm not sure about loading the project files and such. VB is useless to me, VC may also be good
[00:25:14] <tomp2> ah, I got BC-- DeBuilder 5
[00:25:16] <SWPadnos> maybe VC and Delphi, then I can mix and match the correct UI descriptions with the C code
[00:25:30] <SWPadnos> heh
[00:25:33] <tomp2> thats what i said was 'notc'
[00:25:48] <SWPadnos> do you mean t he command-line compiler?
[00:26:18] <tomp2> no, a pkg I built soem comm pgms with years ago, definitly gui/form oriented
[00:26:39] <tomp2> but i think there a freebie VB around, a legal one...
[00:26:58] <SWPadnos> eh - I can probably just translate from delphi to BC anyway
[00:27:28] <SWPadnos> those windows were pretty trivial to make up, and the code isn't rocket science either
[00:27:48] <tomp2> pascal to basic, you speak in tounges :), yeah i oughtta look at the src
[00:27:50] <SWPadnos> are you running on windows 2000/XP or a 95/98/ME-style OS?
[00:27:55] <SWPadnos> no, pascal to C
[00:27:59] <tomp2> either, got 'em
[00:28:13] <tomp2> oh BC yeh
[00:28:21] <SWPadnos> ok - I/O is protected on 2k/XP, but not on 95/98/ME
[00:29:06] <tomp2> right i had to stop serial timeouts, and found a trick on w2k, was easy on 98
[00:29:58] <SWPadnos> there are drivers that give you port access, though I'm sure that the timing will be different from ring 0/kernel mode
[00:30:28] <tomp2> i wrote NoTimOut is a cnc spoonfeeder, can use usb, up to a zillion instances at once. was important for slow cnc's like wedm. i make pocket money off it
[00:30:43] <SWPadnos> heh
[00:31:20] <tomp2> lookin at code, l8r
[00:31:24] <tomp2> thx
[00:32:09] <SWPadnos> okie
[00:32:11] <SWPadnos> see you
[00:36:14] <jepler> tomp2: hah sheesh
[00:36:31] <SWPadnos> hashish?
[00:36:34] <jepler> no
[00:36:39] <SWPadnos> phewe
[00:36:41] <SWPadnos> -e
[00:36:51] <tomp2> Kolter-DLL Deklarationen fuer KlibDrv.DLL hey a german guy write the code
[00:36:53] <jepler> it's just becoming clearer and clearer that the folks who designed these cards .. didn't do a very good job of it
[00:38:27] <tomp2> i remember it used to blink an led at rear of card, under W$, it doesnt now, i thin maybe we dont talk to it the way it wants to be talked to, maybe (IMO)
[00:40:39] <rayh> kiss kiss bang bang -- oh honey?
[00:41:49] <jepler> if polling the card at more than 10Hz while applying 5V to an input through a 2.2k resistor is enough to kill it .. it's not a card that'll live long.
[00:43:01] <SWPadnos> but, will it work with 24V?
[00:43:06] <SWPadnos> like my encoder
[00:43:07] <jepler> guessing .. no
[02:08:39] <tomp2> found vb6 on another partition, built app with B000, running now, but need to test real i/o, not just vb forms
[11:57:23] <fenn_> fenn_ is now known as fenn
[12:18:17] <skunkworks> this dell has been running all night - still <10us
[12:18:37] <skunkworks> and it didn't burn up with smi disabled ;)
[12:35:46] <rayh> Morning skunkworks That can't be all bad then.
[12:37:02] <jepler> hi rayh, skunkworks
[12:37:09] <skunkworks> morning
[12:37:40] <rayh> How you doing jepler?
[12:38:19] <jepler> oh, if you get me started I'll complain about what I'm doing at work these days, but aside from that all is going well
[12:40:11] <rayh> I recall been in similar situations.
[12:45:07] <skunkworks> rayh: finally warm up there?
[12:46:18] <skunkworks> alex_joni: did rtai_smi now come with the latest rtai - or did you add it for us?
[12:47:06] <rayh> Not to bad. frost this morning but looks like a nice day.
[12:47:13] <skunkworks> Sunny here.
[12:49:39] <skunkworks> jepler: Still thinking the futurlec card is crap?
[12:50:56] <alex_joni> skunkworks: it was there..
[12:51:14] <alex_joni> actually it was in the old rtai as well, but had some bugs.. maybe I should build an update for dapper with the fix
[12:51:17] <jepler> skunkworks: yeah
[12:51:44] <alex_joni> hey guys
[12:51:58] <alex_joni> * alex_joni is in his t-shirt
[12:52:28] <alex_joni> a bit chilly atm at 68F, but usually it's warmer
[12:53:26] <skunkworks> looks like the best solution then is another mesa card.
[12:54:08] <skunkworks> alex_joni: did you see the imagebin?
[12:54:35] <alex_joni> skunkworks: I think so..
[12:54:41] <alex_joni> the one with < 10usec latency?
[12:54:54] <alex_joni> http://imagebin.ca/view/bmhQu9.html
[12:55:16] <skunkworks> yes - it lookes exactly the same this morning :)
[12:55:24] <alex_joni> cool
[12:55:29] <alex_joni> sounds like a very good machine
[12:55:54] <skunkworks> actually - 9852 now. but still
[12:56:01] <jepler> skunkworks: peterw apparently has some new I/O expander boards that will go together with the 5i20 but I don't think they're ready yet, and they also will require emc driver changes to work.
[12:56:38] <alex_joni> skunkworks: what machine is it? some special brand/model?
[12:57:30] <alex_joni> jepler: latency-test only accounts for positive jitter.. right?
[12:58:53] <jepler> jitter = max(max_ - period, period - min_);
[12:59:07] <jepler> if the negative jitter is greater than the positive jitter, then that value would be shown instead
[12:59:36] <jepler> maybe I should use some other calculation than that
[13:03:26] <alex_joni> I'm just thinking of the "worst" case when there's on cycle when it comes very early (negative jitter) and the next when it is very late (positive jitter)
[13:03:52] <alex_joni> so it ends up to : period-min + max-period
[13:27:13] <skunkworks> alex_joni: optiplex gx270
[13:27:30] <skunkworks> it had 60us latency before smi
[13:31:55] <skunkworks> yikes. I think john speaks for us. :) (takes one for the team)
[14:17:28] <skunkworks> cool - looks like even the onboard video works. (I had added a card trying to troubleshoot the high latency issue)
[16:02:22] <skunkworks> alex_joni: saw that. I am going to add a few.
[17:55:58] <skunkworks> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Latency-Test
[17:56:17] <skunkworks> I have a question - why is there a ? by the first one?
[17:56:35] <skunkworks> * by the asus gforce?
[18:02:12] <skunkworks> alex_joni: thought - can you atleast turn off the shutdown spash screen? (so it is text) otherwise your not really sure why you can shut it down.
[18:03:42] <skunkworks> * when
[18:11:25] <cradek> skunkworks: GeForce is a wiki word because of the caps, but there is no GeForce wiki page
[18:12:56] <fenn> skunkworks: google "camel case"
[18:13:23] <LawrenceG> cradek, hi Chris.... have you ever written a drag and drop client?.... wondering how hard it would be for axis to accept gcode files via drag and drop
[18:14:00] <skunkworks> ah - makes sense - thanks cradek and fenn
[18:14:25] <cradek> LawrenceG: sorry, no idea here
[18:15:15] <LawrenceG> np.... I will keep my eyes open for an example.... should be just a system message that needs handling
[18:15:35] <cradek> I think DnD is one of those things that doesn't necessarily work between toolkits
[18:15:43] <jepler> LawrenceG: Tk does not directly support the drag&drop standard adopted by gnome and kde, so you have to write a bunch of code to enable it.
[18:15:45] <cradek> so DnD from gnome to tk may be hard or impossible
[18:17:01] <LawrenceG> bummer... you would think the toolkits would be mature enough to support one of the basic gui ops system wide
[18:17:35] <cradek> sometimes immature apps get along better because they were all written about the same time
[18:17:41] <jepler> tk is too mature -- it doesn't follow these "new" standards
[18:17:57] <jepler> it has its own, older D&D standard, and you might as well complain that gnome and kde ignored the existing state of the art
[18:18:37] <jepler> though it looks like somebody may have implemented the newer D&D standard for tk, I have never tried it:
http://www.iit.demokritos.gr/~petasis/tcl/tkDND/tkDND.html
[18:19:07] <jepler> (doesn't appear to be packaged on debian/ubuntu)
[18:19:14] <LawrenceG> looking
[18:20:07] <jepler> hm the source code link on that page is dead, as well
[18:22:23] <LawrenceG> hmmm looks like bwidget has dnd support of some kind
[18:22:51] <jepler> yes but I am almost 100% certain it is not gnome-compatible
[18:30:52] <LawrenceG> http://wiki.tcl.tk/16126 might be of some use.... will see if I can figure it out
[18:34:37] <jepler> unless you read something to the contrary, bwidget drag & drop will *not* accept drops from gnome
[18:49:20] <jepler> I tried compiling various versions of "tkdnd" (the one that is supposed to accept drops from gnome) but in the two versions I tried (alpha or cvs) it either shows an error or crashes when trying to drag from gnome file browser to its drop site
[18:52:26] <LawrenceG> interesting..... I typically put the gcode files for a particular project on the desktop.... ie drill.ngc, mill.ngc, route.ngc steps for pcb's .... it would be nice to be able to drag these onto an open axis window to load them
[18:52:48] <jepler> I don't disagree .. but there are technical barriers that make it something other than trivial to do
[18:53:20] <LawrenceG> I completely understand that its a SMOP :}
[18:53:35] <LawrenceG> well... maybe not so simple
[18:55:13] <LawrenceG> I didnt realize DND was so bloated.... dropping controls, list entities and such.... All I wanted was a filename that could be used with the load file code.
[19:01:00] <LawrenceG> time to go cut the grass... maybe something will come to me.... cheers
[19:07:46] <jepler> I only tested this the tiniest bit, but this .desktop file creates an icon that you can drag a gcode file to. if emc's running with axis as the gui, axis should load the file. (if it's not, it silently does nothing)
[19:07:50] <jepler> http://emergent.unpy.net/files/sandbox/axis-remote.desktop
[19:08:48] <cradek> cool, I wondered if axis-remote would be the way to do it.
[19:51:53] <fenn> LawrenceG: can't you just set .ngc files to be opened with axis-remote?
[19:52:54] <jepler> I thought about that but figured he wanted to reserve double-click for "open in editor"..
[19:53:47] <fenn> in kde there's an 'open with' submenu, that conceivably could list AXIS
[19:55:31] <LawrenceG> open with axis remote worked like a charm
[19:56:30] <LawrenceG> now I can right click on ngc file and use the open with.... just about drag and drop and no extra desktop icons required
[19:56:59] <jepler> yeah there are probably a bunch of different ways to configure axis-remote .. it depends what you prefer
[19:57:22] <LawrenceG> thankyou much guys
[19:57:41] <jepler> turned out I didn't have to do any programming, so I am more than happy to have done that for you
[19:58:04] <alex_joni> heh
[19:59:15] <skunkworks> alex_joni: did you see my comment above?
[20:01:57] <fenn> http://fennetic.net/pub/irc/rs274-mimetype.png <- this was done with 'keditfiletype text/rs274ngc'
[20:02:00] <alex_joni> yeah, I saw it..
[20:02:05] <alex_joni> but I don't think it's possible
[20:02:13] <skunkworks> darn
[20:02:14] <alex_joni> (without turning off boot splash too)
[20:02:37] <skunkworks> I would not have a problem with that.. maybe it should be put to a vote or something.
[20:02:55] <alex_joni> skunkworks: you can always remove "splash" from your /boot/grub/menu.lst
[20:03:08] <alex_joni> I think you need to change splash to nosplash
[20:03:28] <skunkworks> I will give it a try
[20:04:05] <alex_joni> I'm not sure I'm comfortable changing grub defaults/related things
[20:19:04] <alex_joni> jepler: I get some warnings while running stepconf (it seems to work ok though..)
[20:19:59] <alex_joni> http://pastebin.ca/1011976
[20:20:54] <jepler> alex_joni: yeah I think those are harmless. I think they just indicate that there's not a .mo file for the language you're using (as there would not be for english)
[20:21:30] <alex_joni> LANG="en_US.UTF-8"
[20:21:56] <jepler> though I'm less sure about the gdk_pixbuf_new_from_file warning
[20:28:28] <rayh> Hey alex_joni. You around and able to answer a few questions?
[20:29:06] <rayh> oops. catch you tomorrow alex. good night.
[20:32:01] <cradek> those darn timezones
[20:37:03] <rayh> Don't you hate it.
[20:37:16] <rayh> You got a few minutes?
[20:37:32] <cradek> no more than 23
[20:37:42] <rayh> More than enough.
[20:38:24] <rayh> I've heard talk of user space timed HAL modules.
[20:38:42] <rayh> halui and such
[20:39:41] <rayh> What happens if a stepgen pin gets connected to something less time deterministic.
[20:40:47] <alex_joni> rayh: still barely here :)
[20:40:54] <cradek> the userland thing only reads/writes the hal pin when it gets around to it
[20:41:09] <cradek> the realtime thing can read/write the hal pin with guaranteed timing
[20:41:13] <rayh> For example. If we were able to write a simple user space driver for a mesa 5ixx
[20:41:27] <cradek> this works because a read/write of a pin doesn't have to be acknowledged by the other side
[20:41:31] <rayh> using USB
[20:42:36] <cradek> for example userland USB stuff could be great for halui stuff. it is nonrealtime, just like the guis
[20:42:52] <rayh> It would fail miserably at step pulse generated signals.
[20:43:19] <rayh> but would be fine with switches like close spindle collet or some such.
[20:43:30] <cradek> yes because even though stepgen would have good timing at its output, your userland hardware driver would sometimes miss some of it
[20:44:04] <cradek> yes especially for something like tool change, where the realtime stuff all just waits until it's done, it would be perfectly fine
[20:44:28] <rayh> So I would have to be careful what I hook to what.
[20:44:53] <cradek> yes if you have nonrealtime hardware, you can only hook stuff to it that you don't need to read/write with guaranteed timings
[20:45:18] <cradek> seems like nonrealtime modbus for vfd control would be fine, for instance. spindle response is slow anyway.
[20:45:26] <rayh> So the rt v user signal demands are all up to me.
[20:45:58] <cradek> yes I guess so
[20:46:52] <cradek> userland is usually pretty responsive but you'd have to consider what would happen if your userland stuff went away for a few seconds. it is sure possible that this can happen.
[20:47:18] <rayh> Okay.
[20:47:48] <cradek> do you have a specific thing in mind?
[20:48:39] <rayh> A user timed USB link to the mesa 7i43
[20:49:18] <cradek> I think that could be a great way to make a front panel
[20:49:19] <rayh> with all of the 48 signals being GPIO
[20:49:26] <rayh> Exactly
[20:49:38] <rayh> or a tool changer using only sensors and solenoids.
[20:49:45] <cradek> estop must not be on it of course
[20:49:52] <rayh> You bet.
[20:49:52] <cradek> but otherwise, sure
[20:50:13] <rayh> Thanks Chris. I'll persue it with Seb a bit.
[20:50:29] <cradek> tool change is another good one because like I said, emc just waits for it to finish anyway
[20:50:59] <cradek> sounds fascinating. go ahead and send me a front panel when you're done!
[20:51:47] <cradek> hmm, also, jogwheel would have to be read in realtime to work correctly.
[20:52:20] <cradek> that's the only special case I can think of.
[20:53:12] <rayh> You bet.
[20:53:42] <cradek> I would not be at all surprised if there is already a GPIO firmware for 7i43 that makes it a HID device. You could just use hal_input then.
[20:54:33] <rayh> There is and a similar one in our code already.
[20:54:39] <jepler> depending on the USB interface chip they use that may not be possible.
[20:54:53] <jepler> also, the output options are limited in that case
[20:55:05] <cradek> Configurations are provided for simple GPIO, Smart Motion control (SoftDMC), host based motion control (HostMot2), and a waveform generator.
[20:55:27] <cradek> that must mean there's a GPIO firmware already. At worst case that just means you need a matching HAL driver
[20:55:32] <rayh> jepler, output options?
[20:55:45] <jepler> rayh: yeah, indicators or whatever
[20:55:56] <jepler> the only thing that hal_input supports for outputs is the equivalent of keyboard LEDs
[20:56:05] <cradek> oh I see, keyboards/mice/etc don't have much output do they
[20:56:51] <jepler> rayh: do you have one of these boards handy? what's the chip on it that is close to the USB connector but not a Xilinx chip?
[20:57:00] <fenn> how many 'keyboard leds' can you have?
[20:57:07] <rayh> You're saying I can't have 24 in and 24 out?
[20:57:16] <rayh> I don't have one here yet.
[20:57:18] <cradek> A FTDI FT245R USB interface chip is used for the USB interface.
[20:57:19] <jepler> rayh: OK
[20:57:23] <jepler> cradek: thanks
[20:57:32] <jepler> that chip does not have the ability to do USB HID as far as I know.
[20:57:39] <cradek> ah ok
[20:57:45] <rayh> What's HID
[20:57:46] <cradek> forget what I said about that
[20:57:50] <cradek> human input something
[20:58:00] <cradek> like keyboard/mouse/joystick on a pc
[20:58:15] <fenn> human interface device
[20:58:18] <jepler> rayh: Human Interface Device -- basically a protocol that is generic enough to allow for most types of input devices
[20:58:34] <jepler> in addition to what cradek listed, it is intended to support joysticks, wheels, and more
[20:58:54] <rayh> Oh okay. But if I'm connecting the USB between the 48 pins on the mesa and a HAL module that reads and writes them am I okay?
[20:58:59] <jepler> (in fact, it has perfectly good support for outputs beyond keyboard LEDs, but the Linux "input device" layer does not)
[20:59:25] <jepler> rayh: yes, you're fine if you follow whatever documentation mesa furnishes for communicating with it
[21:00:02] <rayh> Okay. That sounds like what I'm thinking might just work.
[21:00:02] <cradek> rayh: yes "all" you need is a userland hal driver. it can use all the existing linux usb infrastructure and should be fairly straightforward to write.
[21:00:27] <cradek> "Drivers are available for Windows and Linux."
[21:00:37] <rayh> Sort of modular, USB or Ethernet control of sets of devices like tool changes and pallet changers and such
[21:00:39] <cradek> could be as simple as adding hal pins to their driver code and recompiling.
[21:00:48] <rayh> Really.
[21:01:06] <rayh> That sounds way to easy.
[21:02:25] <rayh> Thanks for the help guys.
[21:02:50] <cradek> um, there is assembler and pascal in their 'support software' zip file
[21:03:38] <rayh> you thinking p2c?
[21:03:49] <cradek> sorry, I have no idea what this stuff is
[21:04:08] <cradek> doubt it's for linux. there must be something else somewhere else.
[21:04:09] <rayh> a converter from pascal to C for code.
[21:04:14] <jepler> looks like ubuntu 6.06 has libftdi0 / libftdi-dev which says it communicates with FT245 chips
[21:04:18] <rayh> Oh.
[21:06:29] <cradek> Description: Library to control and program the FTDI USB controller
[21:06:29] <cradek> This library could talk to FTDI's FT232 and FT245 type USB chips from
[21:06:29] <cradek> userspace. It uses libusb to communicate with the chips.
[21:06:43] <cradek> ok I'm back to thinking it might be pretty easy then.
[21:07:05] <cradek> I bet this is what mesa means with "Drivers are available ... for Linux"
[21:08:36] <cradek> $89 qty 1
[21:08:47] <cradek> it's interesting to compare that to the pluto
[21:09:07] <jepler> it beats the stuffing out of the pluto
[21:09:12] <jepler> sane I/O connector layout
[21:09:13] <cradek> yep
[21:09:16] <jepler> bigger FPGA
[21:09:32] <jepler> FPGA firmware written by someone more competent than me
[21:09:37] <cradek> ha
[21:09:55] <rayh> Sounds like I'd better order mine today!
[21:09:57] <fenn> and a slightly less evil fpga manufacturer
[21:10:17] <jepler> oh yeah, I forgot "can develop under linux without paying for an SDK"
[21:10:50] <cradek> yay mesa
[21:11:09] <fenn> the accessories are nice too
[21:11:32] <rayh> PeterW said there is an Ethernet version in the works.
[21:12:36] <rayh> I do like the 48 volt capable io boards.
[21:13:36] <cradek> for these two applications I see no benefit to using ethernet. in fact it seems somewhat worse
[21:14:01] <jepler> the only advantage i see is ethernet = electrical isolation
[21:14:06] <skunkworks> wouldn't it be easier to support rt eithernet if you only have to support 1 card/chipset for now? Like an intel chipset and make people spend 10 dollars for a pci card?
[21:14:06] <rayh> ??
[21:14:08] <cradek> who has a spare ethernet port [very few]. who has a spare usb port [everyone].
[21:14:40] <rayh> I can see that.
[21:14:41] <cradek> rayh: for the two nonrealtime applications: front panel, tool changer
[21:14:49] <fenn> uh.. actually i'd think ethernet would be much easier to deal with (if it handled IP properly)
[21:15:06] <rayh> I've always thought that I'd use a dedicated ether card with several drivers on it.
[21:15:59] <rayh> I guess skunkworks and I are thinking kinda alike. Scary eh.
[21:16:32] <fenn> skunkworks: i think there already is an emc rtnet driver floating out there?
[21:17:08] <fenn> or maybe i'm just confusing it with the ethercat driver
[21:17:22] <skunkworks> I think it has been descussed on the list a few months back
[21:17:41] <jepler> various people have talked about rtnet + emc but I don't know where any actual code is
[21:19:47] <fenn> Evert Lammerts claims to have gotten something working
[21:19:59] <skunkworks> wow - I have a bunch of dells here that have the 82845 or similar chipset.
[21:20:03] <rayh> I'm thrilled that this user space thing looks as doable as you think it is.
[21:20:21] <rayh> That opens up a lot of possibilities.
[21:21:30] <jepler> ooh time to go home
[21:22:59] <rayh> Thanks again.
