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.
if you have the source, I can probably make a new exe for you
SWPadnos: I'd like to try that, would you like VB VC or Delphi src?
i think you'd just chg the address
before i trash the 160$
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
ah, I got BC-- DeBuilder 5
maybe VC and Delphi, then I can mix and match the correct UI descriptions with the C code
thats what i said was 'notc'
do you mean t he command-line compiler?
no, a pkg I built soem comm pgms with years ago, definitly gui/form oriented
but i think there a freebie VB around, a legal one...
eh - I can probably just translate from delphi to BC anyway
those windows were pretty trivial to make up, and the code isn't rocket science either
pascal to basic, you speak in tounges :), yeah i oughtta look at the src
are you running on windows 2000/XP or a 95/98/ME-style OS?
no, pascal to C
either, got 'em
oh BC yeh
ok - I/O is protected on 2k/XP, but not on 95/98/ME
right i had to stop serial timeouts, and found a trick on w2k, was easy on 98
there are drivers that give you port access, though I'm sure that the timing will be different from ring 0/kernel mode
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
lookin at code, l8r
tomp2: hah sheesh
Kolter-DLL Deklarationen fuer KlibDrv.DLL hey a german guy write the code
it's just becoming clearer and clearer that the folks who designed these cards .. didn't do a very good job of it
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)
kiss kiss bang bang -- oh honey?
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.
but, will it work with 24V?
like my encoder
guessing .. no
found vb6 on another partition, built app with B000, running now, but need to test real i/o, not just vb forms
fenn_ is now known as fenn
this dell has been running all night - still <10us
and it didn't burn up with smi disabled ;)
Morning skunkworks That can't be all bad then.
hi rayh, skunkworks
How you doing 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
I recall been in similar situations.
rayh: finally warm up there?
alex_joni: did rtai_smi now come with the latest rtai - or did you add it for us?
Not to bad. frost this morning but looks like a nice day.
jepler: Still thinking the futurlec card is crap?
skunkworks: it was there..
actually it was in the old rtai as well, but had some bugs.. maybe I should build an update for dapper with the fix
* alex_joni is in his t-shirt
a bit chilly atm at 68F, but usually it's warmer
looks like the best solution then is another mesa card.
alex_joni: did you see the imagebin?
skunkworks: I think so..
the one with < 10usec latency?
[12:54:54] <alex_joni> http://imagebin.ca/view/bmhQu9.html
yes - it lookes exactly the same this morning :)
sounds like a very good machine
actually - 9852 now. but still
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.
skunkworks: what machine is it? some special brand/model?
jepler: latency-test only accounts for positive jitter.. right?
jitter = max(max_ - period, period - min_);
if the negative jitter is greater than the positive jitter, then that value would be shown instead
maybe I should use some other calculation than that
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)
so it ends up to : period-min + max-period
alex_joni: optiplex gx270
it had 60us latency before smi
yikes. I think john speaks for us. :) (takes one for the team)
cool - looks like even the onboard video works. (I had added a card trying to troubleshoot the high latency issue)
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
I have a question - why is there a ? by the first one?
* by the asus gforce?
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.
skunkworks: GeForce is a wiki word because of the caps, but there is no GeForce wiki page
skunkworks: google "camel case"
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
ah - makes sense - thanks cradek and fenn
LawrenceG: sorry, no idea here
np.... I will keep my eyes open for an example.... should be just a system message that needs handling
I think DnD is one of those things that doesn't necessarily work between toolkits
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.
so DnD from gnome to tk may be hard or impossible
bummer... you would think the toolkits would be mature enough to support one of the basic gui ops system wide
sometimes immature apps get along better because they were all written about the same time
tk is too mature -- it doesn't follow these "new" standards
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
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
(doesn't appear to be packaged on debian/ubuntu)
hm the source code link on that page is dead, as well
hmmm looks like bwidget has dnd support of some kind
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
unless you read something to the contrary, bwidget drag & drop will *not* accept drops from gnome
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
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
I don't disagree .. but there are technical barriers that make it something other than trivial to do
I completely understand that its a SMOP :}
well... maybe not so simple
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.
time to go cut the grass... maybe something will come to me.... cheers
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
cool, I wondered if axis-remote would be the way to do it.
LawrenceG: can't you just set .ngc files to be opened with axis-remote?
I thought about that but figured he wanted to reserve double-click for "open in editor"..
in kde there's an 'open with' submenu, that conceivably could list AXIS
open with axis remote worked like a charm
now I can right click on ngc file and use the open with.... just about drag and drop and no extra desktop icons required
yeah there are probably a bunch of different ways to configure axis-remote .. it depends what you prefer
thankyou much guys
turned out I didn't have to do any programming, so I am more than happy to have done that for you
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'
yeah, I saw it..
but I don't think it's possible
(without turning off boot splash too)
I would not have a problem with that.. maybe it should be put to a vote or something.
skunkworks: you can always remove "splash" from your /boot/grub/menu.lst
I think you need to change splash to nosplash
I will give it a try
I'm not sure I'm comfortable changing grub defaults/related things
jepler: I get some warnings while running stepconf (it seems to work ok though..)
[20:19:59] <alex_joni> http://pastebin.ca/1011976
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)
though I'm less sure about the gdk_pixbuf_new_from_file warning
Hey alex_joni. You around and able to answer a few questions?
oops. catch you tomorrow alex. good night.
those darn timezones
Don't you hate it.
You got a few minutes?
no more than 23
More than enough.
I've heard talk of user space timed HAL modules.
halui and such
What happens if a stepgen pin gets connected to something less time deterministic.
rayh: still barely here :)
the userland thing only reads/writes the hal pin when it gets around to it
the realtime thing can read/write the hal pin with guaranteed timing
For example. If we were able to write a simple user space driver for a mesa 5ixx
this works because a read/write of a pin doesn't have to be acknowledged by the other side
for example userland USB stuff could be great for halui stuff. it is nonrealtime, just like the guis
It would fail miserably at step pulse generated signals.
but would be fine with switches like close spindle collet or some such.
yes because even though stepgen would have good timing at its output, your userland hardware driver would sometimes miss some of it
yes especially for something like tool change, where the realtime stuff all just waits until it's done, it would be perfectly fine
So I would have to be careful what I hook to what.
yes if you have nonrealtime hardware, you can only hook stuff to it that you don't need to read/write with guaranteed timings
seems like nonrealtime modbus for vfd control would be fine, for instance. spindle response is slow anyway.
So the rt v user signal demands are all up to me.
yes I guess so
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.
do you have a specific thing in mind?
A user timed USB link to the mesa 7i43
I think that could be a great way to make a front panel
with all of the 48 signals being GPIO
or a tool changer using only sensors and solenoids.
estop must not be on it of course
but otherwise, sure
Thanks Chris. I'll persue it with Seb a bit.
tool change is another good one because like I said, emc just waits for it to finish anyway
sounds fascinating. go ahead and send me a front panel when you're done!
hmm, also, jogwheel would have to be read in realtime to work correctly.
that's the only special case I can think of.
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.
There is and a similar one in our code already.
depending on the USB interface chip they use that may not be possible.
also, the output options are limited in that case
Configurations are provided for simple GPIO, Smart Motion control (SoftDMC), host based motion control (HostMot2), and a waveform generator.
that must mean there's a GPIO firmware already. At worst case that just means you need a matching HAL driver
jepler, output options?
rayh: yeah, indicators or whatever
the only thing that hal_input supports for outputs is the equivalent of keyboard LEDs
oh I see, keyboards/mice/etc don't have much output do they
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?
how many 'keyboard leds' can you have?
You're saying I can't have 24 in and 24 out?
I don't have one here yet.
A FTDI FT245R USB interface chip is used for the USB interface.
that chip does not have the ability to do USB HID as far as I know.
forget what I said about that
human input something
like keyboard/mouse/joystick on a pc
human interface device
rayh: Human Interface Device -- basically a protocol that is generic enough to allow for most types of input devices
in addition to what cradek listed, it is intended to support joysticks, wheels, and more
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?
(in fact, it has perfectly good support for outputs beyond keyboard LEDs, but the Linux "input device" layer does not)
rayh: yes, you're fine if you follow whatever documentation mesa furnishes for communicating with it
Okay. That sounds like what I'm thinking might just work.
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.
"Drivers are available for Windows and Linux."
Sort of modular, USB or Ethernet control of sets of devices like tool changes and pallet changers and such
could be as simple as adding hal pins to their driver code and recompiling.
That sounds way to easy.
Thanks for the help guys.
um, there is assembler and pascal in their 'support software' zip file
you thinking p2c?
sorry, I have no idea what this stuff is
doubt it's for linux. there must be something else somewhere else.
a converter from pascal to C for code.
looks like ubuntu 6.06 has libftdi0 / libftdi-dev which says it communicates with FT245 chips
Description: Library to control and program the FTDI USB controller
This library could talk to FTDI's FT232 and FT245 type USB chips from
userspace. It uses libusb to communicate with the chips.
ok I'm back to thinking it might be pretty easy then.
I bet this is what mesa means with "Drivers are available ... for Linux"
$89 qty 1
it's interesting to compare that to the pluto
it beats the stuffing out of the pluto
sane I/O connector layout
FPGA firmware written by someone more competent than me
Sounds like I'd better order mine today!
and a slightly less evil fpga manufacturer
oh yeah, I forgot "can develop under linux without paying for an SDK"
the accessories are nice too
PeterW said there is an Ethernet version in the works.
I do like the 48 volt capable io boards.
for these two applications I see no benefit to using ethernet. in fact it seems somewhat worse
the only advantage i see is ethernet = electrical isolation
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?
who has a spare ethernet port [very few]. who has a spare usb port [everyone].
I can see that.
rayh: for the two nonrealtime applications: front panel, tool changer
uh.. actually i'd think ethernet would be much easier to deal with (if it handled IP properly)
I've always thought that I'd use a dedicated ether card with several drivers on it.
I guess skunkworks and I are thinking kinda alike. Scary eh.
skunkworks: i think there already is an emc rtnet driver floating out there?
or maybe i'm just confusing it with the ethercat driver
I think it has been descussed on the list a few months back
various people have talked about rtnet + emc but I don't know where any actual code is
Evert Lammerts claims to have gotten something working
wow - I have a bunch of dells here that have the 82845 or similar chipset.
I'm thrilled that this user space thing looks as doable as you think it is.
That opens up a lot of possibilities.
ooh time to go home