i wrote the VB code for outputs, ran fine
i wrote the vb code for inputs and got hard lock
that was with all inputs floating
and same with 1 input pulled up to +5 thru 2.2K
now running with all inputs pulled down to GND thru 2.2K's
i dont understand the input scheme
but i read that there's a bunch of i/o boards designed to hang onto those ide cnxrs
now a jmpr from +5 to another 2.2k to the signal end of the pull downs shows it toggle
tested all 8 ok
no hard lucks ;)
oh, 100ms polling period
timestamp sez 10 min cool
100ms seemed to work on Linux too, at least some of the time :)
going to chg now,
is it repeatable that it locks with floating inputs but not when they're pulled either high or low?
so far that is repeatable, tho i dont like the test ;)
how is the delay done?
a param to a call
read / update display / sleep ?
internals I dont know, it's a lib that i asked for src from ETT, but no reply
I'm suspicious that it's a "wait a millisecond" after all processing is done, so the actual loop time is likely to be longer
but , no lock
<do work for 30 ms><pause for 1ms> is different from <read every 1ms> :)
i can scope outputs and maybe make a counter for a known pulse input
like a waveform gnr8r and a counter
enuf for today
learning VB was a pain
if you have some outputs, then scoping those will be easiest/best, I think
why not use BCB?
at least it's C
outputs may not have the delay that inputs have
it lets you see the actual loop time
i 'll buy the carcasses that others dont like, i think this stuff works and wasnt understood
but for another day, gnite & thx
VB is very much not RT, so when you sleep for 1ms, it will probably do all the screen updates, then let any other programs run, then wait a millisecond or two, then return to your code :)
leave it the same, just set one port to output and toggle a bit each loop
will try ... oh, this is the card that was 'bad' , i just pulled the 8255 and plugged #2 into #1 so it's got some guts
it didnt fry the bridge anyway
see you. thanks for beating on it
EMC: 03jepler 07TRUNK * 10emc2/docs/man/man3/rtapi_outb.3rtapi: whoops, didn't show prototype for rtapi_inb
EMC: 03jepler 07v2_2_branch * 10emc2/docs/man/man3/rtapi_outb.3rtapi: from TRUNK: show prototype for rtapi_inb
pci8255 ran all night at 1ms poll period, and is alive this morning
tomp2: so you think the critical thing was to add pull-downs to the 8255 I/O pins?
I question whether a 1ms poll period is actually 1ms
best I can tell. when i noticed they had so many add on boards I figgered the inputs were soemthing besides what i tried
but an 82c55 chip should operate properly without pullups or pulldowns on its I/O pins
chip 1 port A has xtra stuff on the pcb, some O/C stuff, may affect ins somehow
open colloector driver chip for outpurts... may affect inputs soemhow
i think the extra stuff near chip 1 is concerned with the relay (not driven by 8255) and with generating the chip select signals
I'll ask for a schema tho i have gotten no replies, some old notes they did send helped a lot, they're specific to V3 rev
btw: the green light is 'powered up', the yellow led is relay
* skunkworks_ think then it does have something to do with input state switching.. :)
inputs switching could also point at power issues
skunkworks might have a better power supply, which would make problems less frequent
switching inputs do cause a dynamic load
so if jepler's PC has a worse power supply, or is noisier (causing more input switching), then that could cause more problems
so - BA capasitor on the supply for the card? ;)
I could stick it into one of these dells for grins.
i gotta work on other stuff today but will read the logs, thx
wow, ray's class ideas sound great
I'm thinking it would be good to have an installation demo like every hour or two
you mean OS install?
take PC, wipe HD, insert disc and demo from there
this is how hard it is ...
yeah, it's SO easy
it's OS easy :)
how about a large-ish disk, and on each install a new 4G partition :D
* alex_joni snickers about 20-30 grub items for multi-boot installs
I have 15 or so 4G SCSI disks, we can give them away after the demos ;)
(not enough controllers, but we don't have to tell them that)
hmm.. that resumes to a big mobo with lots of PCI slots
no, one at a time
install, pick a winner, give them the drive
lather, rinse, repeat
* alex_joni wonders what they will think when they get back home and notice the connectors won't fit..
issue with that - what happens when they put it into thier motherboard?
man emc has terrible hardware support -- they can't even use standard hard drives!
skunkworks_: if they manage to connect them.. they get my admiration :D
we'll be long gone by then. muahahahahaha
you can connect 3 SCSI hard drives to a Mesa 5i20
they won't do anything, but you can connect them
step right up.. See the free os install that takes less than 20 minutes.. Step right up.
jepler: running your 8255.hal file right now.
with a big cap added, pull-up/down resistors added, or "stock"?
skunkworks_: what did you change? did you add pull-downs too?
are you expecting a different result than earlier for some reason?
it ran for a good 5 minutes.. the second I plugged in my ribbon cable to plug 1 - the computer locked up.
lets try it again
I put it in a different computer.. 3rd one now.
wow, alex pulled off homing on STG1. I don't think he even had a card, and I think that's the card that's full of stupid regarding homing
cradek: might be ;)
but I also got a couple of patches during the devel cycle (couple years/months)\
was it stg1 or 2 that had the terrible pairs of encoders sharing registers or whatever
I can't believe dave was using 2.0.0 all this time
skunkworks: yes will run a whilel w/o cable, and less with ( all w/o pulldowns ) thats one of the bits that led me to try pulldowns
with cabl you may see the inputs flicker before death ( another reason to push/pull the lines )
adding the cable adds capacitance
cradek, He gets a system working and stays with it.
in my own testing I was inconsistent about having a cable or not, that could explain why I saw variations in how fast things would go wrong
my notes same way
I had to convince him to boot a live cd and test before he'd change.
But that proves the value of the live boot.
try the fanuc live cd to see if you want to upgrade ;)
two years ago (I think) I even fixed a bug that was biting him (G18/G19 arcs with G43)
His board is a 600 MHz with ISA slot.
he must have never got the bugfix until now
no, just give them 1M$
If I remember, I compiled that fix here and sent to him.
He was jumping for joy yesterday when the system came to life.
sooooo much is better since 2.0.0
He said he had a breath taking moment when it homed on index for the first time.
That time between switch and index pulse.
Was more than a half turn on the first axis.
Then relief, "Oh shit it works!"
I bet that will be handy. he has been going without it for a while!
I'll bet he figures out spindle orient and tool change during fest.
he changes tools manually now?
orient is the most finicky part of the tool change on that machine - I wish there was a better way to do it
The casting at the top of the spindle is different on his machine that Roland's.
Some mazak machines had a regular encoder up there and the orient was a card on the spindle drive.
Those would be trivial.
do any machines have a heart cam and simple solenoid for orient?
Yes. The Mood Hydrapoints I had were a bit like that.
our spindle has a cog.
Then they used the rotation resistance to hold the spindle while a motor turned the retension bar.
Some just used a flat on a wheel up on top.
so - is it the act of the inputs switching getting back to the bus causing problems? or are the inputs switching causing the 8255 to screw up?
still running without the cable plugged in.
you all have defective 8255s if having the inputs switch is screwing them up
I wonder if they're just really prone to latch-up or something
like - even if the thing doesn't lockup with pull-downs.. will it lock up once you start switching the inputs?
did somebody say a chip had gotten warm?
I think tom burned up a chip
skunkworks: i have 8 inputs of port A tied down, and strum across the inputs (like a guitar ) using a pull up, no lockups, and inputs on gui ripple
i will retest the chip, maybe/maybe not
My money is still on the real flaw being in the management of the 8255-side data bus. from that page: "Sudden transients on the power or ground bus, which may occur if large numbers of transistors switch simultaneously, can drive the circuit into latchup."
I had similar dip 8255 chips on several ISA cards and had no problems with them failing.
but reading shouldn't change any significant number of transistor states
tomp2: inputs on the gui ripple? even though they are pulled up - the data changes on them?
" strum across the inputs (like a guitar ) using a pull up, no lockups, and inputs on gui ripple"
no but when both the '245 and the 8255 are driving the 8255-side data bus you get a lot of current through 8255 -- it's not the number of outputs switching, but the current on them
they are being pulled up in succession quickly
anything into a computer will need some conditioning
jepler, true. did you try plugging cables in when you had the data '245 removed?
I doubt I ever had a cable installed when a 245 was removed
ok. if you think of it (and feel like it :) ), try that configuration some time
no, I'm done with that card
bring it to Galesburg, we can hook up a scope to every pin on a '245 and see what happens
21:34:10 <tomp2> i wrote the vb code for inputs and got hard lock
21:34:10 <tomp2> that was with all inputs floating
that points away from data bus management
tomp2, try changing that pull-down to a pull-up SIP
two people both wrote straightforward drivers and both found that it locked up and maybe damaged chips in input mode
that's true, it does sound like it's not worth the trouble
I don't much care if adding external pullups or pulldowns might fix it
there's a lot of emphasis on "might" IMO
but it is such a pretty card...
looks don't matter
SWPadnos: my 1st attempt was a single p/u. so the test is to see if byte wide(port wide) p/u is beneficial, right?
the fact that someone married me proves that ;)
tomp2, yes - checking to see if the number of 1 bits on the data side matters
I don't think it should, but it would show that the data side can handle any data
i'd like to see some of the add-on cards... what they did to i/f hdwr to the card
SWPadnos: will try later, right now have an INAV ctrl being tested on that box http://www.inavcnc.com/
heh, ok :)
will try std mem test patterns, marching 1's etc
oh hey - I saw an interesting thing on a machine yesterday. MDI mode had a multi-line editor, so you could enter several commands then execute them with the cycle start button
Heidenhain MDI is a file & lets you edit that, run that and eventually save as file ( the real 'oops' programming system )
right - this one showed a program number for the MDI editor
presumably you could save/recall using that
fanuc has a multi line mdi also
so somebody should write one for emc
I rarely used it ;)
sounds like a good plan
two ways: directly use nml to send multiple mdi commands in a burst; or use axis-remote so that the user can also preview mdi before executing it
can you use axis-remote when axis is running?
yes, that's the only time its useful
err - that probably was a stupid question :)
the BOSS has "mdi store" on the front panel. it appends the commands to the end of the program you forgot to clear before you started
that's really useful! :)
it makes you enter a tool number and spindle speed too, even though it can't change the tool or set the spindle speed for you
I think multiple MDI commands wouldn't work right - movements would all be exact stop, for instalce (I'm assuming it would work that way anyway)
well the gui could just put them in a file and run it
Long years ago we had an EMC that did just that. A hidden file was sent all kinds of stuff that started up when you pressed run. Kinda scary at times.
rayh: nice wiki. We are planning on coming down on wednesday this year so 'classicladder ladder thrusday' will be great!
Okay. Sounds good.
rayh, do you have any modbus devices you can bring?
Sure. A couple of AD VFDs and a couple AD 106 PLCs
great. I think a userspace modbus driver is possible, using some sort of description language like pyvcp to tell it how to talk to the device
... like pyvcp uses ...
Okay. I can kinda see the thinking.
the main issue I see when thinking about it now is how to share a serial port among different devices
I'd favor a multi card like some of the mesa stuff.
a lot cleaner in my head.
nothing up there any more.
Although we could use the pymod stuff to create a 485 like header.
see you tomorrow guys
off to the hotel, and no wifi there (at least I don't care to pay for it ;)
heh. see you later
id the description language is sufficient, it ouwld be possible to have separate device numbers using the same port
so you'd say "port /dev/ttyS0" somewhere, and only one of those is allowed
And for user space devices, why not.
but later you could have something like several modules, with a base name, device number, and other stuff
tha way you have one serial read/write function, but possibly many devices
then load another instance for another port
(possibly with multiple modules)
Internally route all the ttyS0 mods there.
sort of - the separate module thing is only really necessary because the device number changes, and the HAL names will also likely change
Will loadrt v loaduser handle the two paths.
there wouldn't be any RT involved
it is serial after all
oh - right
Someday we will have an rt path to serial devices
there would be only one component name, like modbus_0
but possibly many pin names, like VFD.speed and modio.out-01
that may be possible, but it isn't necessary
modbus is not RT
sure. If we've got two plcs out there modbus_0 and modbus_1
serial errors cause packets to be discarded, so even if the data arrives "on time", it doesn't guarantee that the data arrives on time (since a retransmit is needed)
Are you thinking all of the modbus devices out there are named modio.out-xx
those were sample pin names
starting with VFD and modio, rather than modbus_0
even though the component name might be modbus_0
and some way the module sorts them out
any module can create a pin with any name
to be confusing, I could have the modbus module create a pin called motion.something :)
What if there are more than one modbus device. Would a single module handle them both.
that's what I was talking about. where were you? :)
I think I'd have one component per serial port though, that should make things simpler
since you can loadusr as many as you want
component meaning a HAL userspace software module
okay then loadusr mycomponent ttyS0 dev1 dev2 devx
where dev1 ... is an outboard device on ttyS0
I'm thinking more like pyvcp, where there's an XML (or other) file that describes what is on the serial bus, which registers need to be read/written, what the device number is, what the pins should be named, etc.
We may have to work up a diagram for this.
so the load line is like "loadusr hal_modbus /dev/ttyS0 devices.xml"
possibly with the port in the XML file
so you'd have "loadusr hal_modbus devices.xml"
That breaks out the logical elements and links between them and their internal pins and params.
Okay. So the XML is charged with handling all of the details.
like pyvcp: you can create an LED with whatever name you want (except it always starts with the component name, I think)
IMO we need to write the XML spec so that it includes instances and inheritance.'
there's a configuration library I ran across recently that lets you specify config parameters in files, environment vars, or on the command line
((probably not important for this discussion)
I'd like to be sure we don't go off having many different config file types, which is the sate we're in now
(ini, xml, hal, scripts, nml, etc)
In my terminology these are all separate languages
anyway, that's a big discussion of the type we should have at Fest :)
Each with their own semantics and syntactics.
And now there's stepconf. I love it but it's another one.
As much as I am hesitant to embrace xml it does permit the range of data we employ in configuration.
well, we need something, and it would be ideal to not have to write it ourselves
I tried that with a couple of my early configurators.
This XML file does not appear to have any style information associated with it
do you mean DTD?
something like that.
what is "this XML file"? :)
Jeff did include a <stepconf> and </stepconf>
so that's a good start
I don't think the file format was the main design goal ;)
No but it becomes a part of that big picture sort of config thing.
If we chose xml
oh - it was in the boost libraries - that command-line option thing
damn, that was hard to find
[15:51:27] <SWPadnos> http://www.boost.org/doc/libs/1_35_0/doc/html/program_options.html
sample code here: http://www.boost.org/doc/libs/1_35_0/doc/html/program_options/tutorial.html
don't strain, it is C++ after all :)
I read that language about as well as Chinese
heh. me too, when they start getting cinto it
Hey I like that.
there's something else provided with KDE (and presumably something similar with gnome) that lets you use command line, environment, and multiple ini files (like system-wide inis, with the ability to tell the config system that certain parameters are not overridable in user configs)
So that's how they do "themes" and such.
So we stop talking about configs and begin talking about, "What's your emc theme?"
I think I like an XML file better.
for something like a mail program, you could set the server as immutable, but let the users change other options (for example)
Gonna be easier to esplain to lucy.
also easier to move complete configs around for troubleshooting purposes
But still that is a pretty interesting bit of code interaction they have going.
yeah - imagine being able to test by doing something like emc --maxaccel=0.5
xml is 1000x worse to hand-edit than .ini
and having that override ini file values
yes, that's possibly an understatement
Sure it is.
And if we move that way we will need parsers for all of it.
one parser to rule them all
the idea would be to have every program use the same calls to get configuration information
we may not be able to get that far though, because parts of the system must be time sequenced (such as connecting pins only after the components are loaded and ready)
and config info is usually not considered that way - it's generally flat data
That's where the "inheritance" comes in.
Or however you high power coders tend to think of it.
at least the inifile parsing library is already exposed to all the languages we use (C, C++, Tcl, Python)
is modbus configuration hard to express in a way that would fit in an inifile?
(that's what started this discussion, right?)
Yes it is.
I think modbus configuration would be more like pyvcp configuration
I'm not sure it would fit well with ini syntax, because the sections need to be defined within the file
I don't think there would be any issues with ini variables creating the modbus connection.
modbus is too generic to define in an ini file
But once you begin to describe the nature of the data you run into issues at both ends.
it's inherently hierarchical - a given device has some parameters associated with it (device number at least)
then you define HAL pins, which have certain registers/coils they connect to, and a HAL name
I'm going to shut up and listen a while.
also type, which could be a bit (for coils), short, long, float (with associated parameters), etc
since an ini file is flat, you either need a section for each pin, with redundant settings saying which device that pin goes to
or you need to list all pins for a particular device within the device section
you'd also need to list all device sections for a given port in the port section
and of course you need to specify how many port sections there are too ...
ini can be done, but it isn't pretty
XML is known to be non-pretty, so we might as well use it :)
_device = /dev/ttyS0
_baud = 9600
# addr type gain offset
spindle-speed-out = 0x300 float 0.025 0.0
spindle-enable-out = 0x304 bit
spindle-direction-out = 0x305 bit
I believe the current ini interface gives us no access to variables with unknown names
so we'd need to know the spindle-speed-out, spindle-enable-out ... names a priori
then fix the library or use pin = spindle_speed_out ... and use the api to get each variable with the same name
yep - thought of the pin= syntax as I was typing
still need to know how many there are though, or get full section access
or parameter arrays or something
there also needs to be a size, since some values are made up from multiple registers
and others are a fraction of a register
also, there are separate address spaces - coils, contacts, registers (and I think another)
with separate commands to read/write them
looks like you can just loop until the inifile.Find method tells you it didn't find an item
oops, real work is calling me
me too, I suppose
Catch you guys later.
wow - 3 computers now needed the rtai_smi
I suspect most sufficiently new intel machines do
pent 3,4 class at the moment
hey skunkworks ...
anyone else had experience/results with smi?
you can load rtai_smi.ko manually to test.
I understand it might help my latency
what kind of latency are you getting?
1.1 ms or so
600 MHz intel P3
no ... video card
what kind of video card?
I really don't know .. been in there forever
probably ati ... not nvidia
ok. do you know what chipset it has?
not offhand ... intel Seattle board ...
do a lspci -v and see what shows up - normally it is towards the top. says 82something
anything else I should try while I'm there
you could just try loading the rtai_smi.ko module for grins.
(then run the latency test)
go to /usr/your-rtai-directory/modules then run sudo insmod rtai_smi.ko
then run latency-test
* skunkworks almost sounds like he know what he is talking about.
are you running hardy or dapper?
if it is dapper - I think you might have to follow the directions on here to put the rtai_smi.ko file into your rtai modules directoy.. I don't think dapper had it by default. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingSMIIssues
whats the damage?
there is a rtai_smi.ko under usr/realtime-2.xxxx-magma/modules but it would not load
so you're using dapper?
my install is a brand new off Live CD which should be dapper ????
took a look at the board and my memory is failing .... video is a nvidia
ok - then I would get the rtai_smi.ko module from the wiki and install it per directions here http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FixingSMIIssues
I grabbed the lspci output on usb but need to retrieve it before it does me any good.
seems to me alex_joni had said something about the rtai_smi that came with rtai was flawed.
heh - it would be nice to know your motherboard chipset from that
give me a bit ...
but - you said nvidia? I wonder what driver it is using.. You may have video driver issues - I know it has been said that even the NV open source driver might give latency issues.
you might try changing it to vesa
(you may have 2 things to look at) :)
I am going to have to leave. Good luck.
darned ..... took too long to get back
I'm printing out the smi instructions and will try them
also will go looking for a better video card
gotta to ... tnx
I got the INAV ctrl up and running 3 axis, it really humms ( sounds like r2d2 :)
so, here's a silly question: how can I use a bash script to start several processes in the background?
I'd like something like for i in seq [1 10] ; do myprogram & ; done
but of course the & doesn't work
SWP ... really dumb question does bash know the difference between myprogram& and myprogram & ?
sure, there's a space between them
or it's one word
a-ha. ; and & are both line terminators, so juse use for blah blah ; test & done