Back
[00:00:06] <Yuga> u just said a whole bunch of word's about it
[00:00:13] <les> oh i'll look
[00:00:24] <les> hello.
[00:00:26] <les> haha
[00:00:49] <les> I know i did with some of that....bad me
[00:01:04] <les> I am not supposed to talk about it
[00:01:14] <les> I know nothing.
[00:01:22] <Jymmm> ok Schultz
[00:01:27] <les> hahaha
[00:02:03] <les> all this law dog stuff has me spooked
[00:02:30] <Jymmm> Only have one thing to say about that les.... Woof!
[00:02:47] <les> hmmm
[00:04:16] <les> any law dogs there and...
[00:04:21] <les> I was lying.
[00:04:28] <les> I was speculating.
[00:04:28] <Jymmm> lol
[00:04:34] <les> I know nothing.
[00:04:43] <les> What I said will not work.
[00:04:54] <les> heh
[00:06:56] <Jymmm> neither will the plausable denyability either!
[00:07:25] <les> Bush does it...why can't I?
[00:07:39] <les> haha
[00:08:03] <les> Now I will attempt some seafood /pasta italian thing
[00:08:12] <les> I have angel hair
[00:08:18] <les> and scallops
[00:08:31] <les> and maui maui or whatever fish
[00:08:37] <les> and clam sauce
[00:09:03] <les> off to the kitchen
[00:10:40] <paul_c> * paul_c returns with coffee & fag
[00:28:22] <zwelch> so, i'm wondering how i should proceed with my emc2 hacking
[00:29:44] <paul_c> do you want cvs access ?
[00:29:57] <zwelch> i suppose that would be the smart thing to do, eh?
[00:30:11] <Jacky^> hello
[00:30:12] <zwelch> * zwelch really doesn't want to fork the code ;)
[00:30:28] <zwelch> * zwelch waves to Jacky^
[00:30:42] <Jacky^> :P
[00:31:02] <les> hi jacky
[00:31:13] <Jacky^> hi guys
[00:31:21] <zwelch> what? a wave isn't synonymous with 'aloha'? :)
[00:31:22] <paul_c> "fork = branch" or "fork = new tree" ?
[00:31:31] <zwelch> fork = new tree
[00:31:33] <les> I am trying to cook an italian seafood dish right now jacky.
[00:31:38] <les> wish me luck.
[00:31:44] <zwelch> i want to branch the code and see the changes merged with HEAD asap
[00:31:52] <Jacky^> les: hehe :)
[00:32:16] <paul_c> I will support and encourage a branch, but I can not condone yet another tree.
[00:33:14] <zwelch> well, we can argue the finer points of my forking theory later, but i agree that - practically speak - forking new trees is a generally unacceptable idea in any concept
[00:33:29] <zwelch> s/concept/context/
[00:33:32] <zwelch> * zwelch sighs
[00:36:40] <paul_c> OK.. lemme throw in another arguement for not creating another tree (or module).. Once created, it can not be removed. The project admins do not have sysadmin control over CVS at sourceforge.
[00:37:25] <zwelch> i want to see projects like EMC be forked, but only if the changes in those "unrelated" trees can be merged back trivially; this requires either a) many many people or b) automation like i am building for GUFT. unless a project has the required momentum or uses GUFT-like tools and processes (which don't yet exist, as an integrated whole), i will not condone the forking of open source projects into new trees.
[00:37:36] <zwelch> well, don't get me started on the limitations imposed by SF
[00:37:50] <zwelch> GUFT is a SF replacement of sorts
[00:39:13] <zwelch> regardless of the CVS limitation, i hope you see that i am not asking for a new tree
[00:39:31] <zwelch> and branches are a bit of a nightmare in CVS too
[00:39:47] <zwelch> i'm happy for you to just point me somewhere and say: play there
[00:41:29] <paul_c> You have a SF usr name of zwelch ?
[00:41:31] <zwelch> * zwelch wonders if switching to SVN has been considered, but doesn't mention it outright because its like asking "vi or emacs"? :)
[00:41:35] <zwelch> paul_c: ayup
[00:41:42] <zwelch> handy, eh? :)
[00:42:49] <paul_c> alex_joni has suggested auto_configure_0_2 branch in emc2
[00:43:03] <paul_c> I would concur
[00:43:09] <zwelch> okee-dokee
[00:44:09] <paul_c> remember - The rcslib/emc trees are for critical bug fixes only. Any new development should be targeted at the emc2 tree.
[00:45:04] <paul_c> Would also suggest an introductory note to the emc-dev list.
[00:46:08] <zwelch> right, i will only muck with emc2 on the specified branch
[00:46:40] <paul_c> you break it, you get to keep all the bits.
[00:56:47] <jepler> zwelch: I would have to guess that EMC is simply using "the version control system that sf.net provides", as opposed to really wanting to use CVS.
[01:06:15] <zwelch> * zwelch has been hosting his own SVN repos for a while now
[01:06:35] <jepler> Not SVK?
[01:06:39] <zwelch> http://svn.guft.org/
[01:06:43] <jepler> or whatever the distributed version is
[01:07:04] <zwelch> i haven't looked at SVK. i've been using SVN since it was at 0.25 or so
[01:07:29] <paul_c> the question of subversions has come up before... No doubt someone will suggest git before to long...
[01:07:37] <jepler> oh, I'm happy to suggest git right now
[01:07:47] <jepler> I'd switch axis over to git if I didn't think cradek would throw a fit
[01:07:56] <zwelch> i contributed some patches to git
[01:08:06] <zwelch> git is not the right RCS ;)
[01:08:22] <zwelch> (for EMC)
[01:08:29] <jepler> I used CVS for myself because at the time it was the one packaged for my distro, and I thought I knew how to run the remote protocol over ssh
[01:08:41] <zwelch> svn was designed to be cvs's replacement
[01:09:05] <jepler> i don't remember whether the other thing I looked at was svn or arch, but I wasn't bright enough to figure out how to run it over ssh
[01:09:27] <zwelch> svn over https is easy
[01:09:38] <zwelch> add a s to the above guft url
[01:09:43] <zwelch> tada secure
[01:10:12] <paul_c> switching to subversion would mean having to set up the project on another server outside of SF
[01:10:50] <zwelch> yeah, so you'd need someone with a server, hosting/bandwith, and the ability to deploy the system you require in short order
[01:10:51] <paul_c> unless you can get all the developers to aggree on such a move, it isn't going to happen.
[01:11:34] <zwelch> well, unless you do it and offer it as a "real, here it is today" alternative, you'll never get all the developers to agree
[01:12:05] <zwelch> i agree talking won't solve the problem, but... if someone were to just do it, what are the odds that everyone could be brought on board
[01:12:21] <zwelch> moreover, there's a board of directors right? wouldn't a decision such as this fall into its purview?
[01:12:23] <paul_c> Two... Fat & zero.
[01:13:21] <zwelch> heh, so you're personally against it anyway?
[01:13:38] <paul_c> indifferent...
[01:21:40] <zwelch> so, i've done a cvs co -r auto_configure_0_2 emc2 && cvs up -j HEAD
[01:21:56] <zwelch> that should bring my branch in-line with HEAD, right?
[01:24:12] <les> just walked in from the music room.
[01:24:23] <les> spirited discussion?
[01:24:37] <zwelch> * zwelch shrugs
[01:24:59] <les> My seafood dinner was good , but too much garlic and pepper. I will have bad dreams tonight.
[01:25:18] <zwelch> mmmm... garlic and pepper :)
[01:25:34] <les> heh
[01:25:53] <les> Well, I am not a developer.
[01:26:13] <les> I just want to see an Enhanced Machine Controller!
[01:26:30] <paul_c> zwelch: Yes. up -j should sync branch with HEAD
[01:27:00] <les> i.e. something open source that would knock the socks off of proprietary stuff out there.
[01:27:21] <les> i.e. servo update rate X 5.
[01:30:27] <zwelch> yeah, actually, i was going to ask you paul_c; les was telling me that EMC is limited to 2KHz for that spec
[01:30:39] <les> it seems
[01:30:43] <paul_c> nope.
[01:30:55] <les> paul thinks he can improve it a bit
[01:31:25] <zwelch> so "more power" == "better hard realtime QoS promises"?
[01:31:30] <paul_c> We experienced some "issues" trying to run a particular build on a 433MHz box
[01:32:08] <zwelch> (you can tack on == "faster feed rates" to the end of the above inquery)
[01:32:23] <paul_c> I didn't look to see if it was hardware related (i.e. a problem with the STG card) or software
[01:32:28] <les> it's nyquist stuff.
[01:34:58] <les> a couple years ago 2 khz updates were the norm
[01:35:05] <les> now about 10 is.
[01:35:47] <paul_c> been looking at some of the DSP solutions....
[01:36:02] <paul_c> 10uSec for a single axis maybe....
[01:36:30] <paul_c> but 2.5 or even 5uSec with multiple axis
[01:36:46] <paul_c> appears to be the "norm"
[01:37:10] <les> yeah some hot dsps can do that easily
[01:37:29] <paul_c> but look at the price of the cards.
[01:37:34] <les> tougher with general purpose up I guess
[01:39:02] <les> chinese labor versus our update rates?
[01:39:10] <les> only shoet term.
[01:39:15] <les> short
[01:40:38] <les> I still have not messed with that kmotion card I got
[01:41:01] <les> it's about 25 uS per axis?
[01:41:09] <les> uses emc interpreter
[01:41:39] <les> but it is not a turnkey machine controller
[01:42:47] <paul_c> lemme update those timings...
[01:43:01] <les> k
[01:43:01] <paul_c> 100uSec for a single axis.
[01:45:09] <les> I fear things will get worse and worse as general purpose up increasingly depend on cache and other ststistical methods for speed
[01:45:42] <paul_c> already happened
[01:45:49] <les> yeah...a lot
[01:46:28] <paul_c> Intel's speculative look ahead cache ruins RT performance...
[01:46:54] <paul_c> Larger on chip caches add additional overheads.
[01:47:32] <paul_c> throw in stuff like onboard graphics sharing main memory
[01:47:38] <les> "speculative" and "RT" are mutually exclusive for sure
[01:47:47] <paul_c> and maybe a scsi disk or two.
[01:47:52] <les> oh my video card triews to do that
[01:48:04] <les> I shurt doen the process
[01:48:10] <les> shut
[01:49:40] <paul_c> any low level hardware that can preempt the processor is bad (like DMA)
[01:49:53] <les> yeah
[01:51:45] <les> Anyway...and this is for zwisk....if an open source machine controller could set the closed source expensive community on it's ear.....that would be earth shaking. Just a user's perspective.
[01:55:53] <zwelch> well, i think the conclusion just reached is that some kind of board would be required
[01:56:15] <les> perhaps not?
[01:56:19] <zwelch> (to handle the RT functionality in a deterministic way)
[01:56:35] <zwelch> (because GP processors are getting too non-deterministic)
[01:56:42] <les> yes
[01:57:27] <zwelch> the least expensive way to do that would be with a PCI (or similar) card
[01:57:38] <zwelch> (and i say that both from the engineering and production perspectives)
[01:58:18] <zwelch> open hardware projects have been done, but they require significant capital
[01:58:39] <les> But.. I am not a developer. How could you make statistical mewthods that favor general pc users work for motion control?
[01:59:05] <les> Ultimately motion control is non deterministic too
[01:59:21] <les> It is conrolled by physical laws
[01:59:32] <zwelch> well, yes, but we're talking about hard RT from an engineering perspective
[01:59:55] <zwelch> the critical part we're talking about is getting the RT portions of the code to run at deterministic times
[01:59:58] <les> feedforward is the answer
[02:00:39] <zwelch> the algorithms being run only matter in so far as the can be run faster than the best possible RT guarantee (if you want to get the most out of your hardware)
[02:01:05] <les> mechanisms don't just do any old thing...they are predictable by relatively simple laws
[02:01:43] <les> simpler than teenage girls on chat groups anyway
[02:02:05] <les> which cache systems seem to be favoring
[02:03:28] <zwelch> well, i guess what i'm saying is that currently EMC uses RT linux. GP processors can't give hard RT promises beyond a certain limit; that limit can be broken if the linux RT portions are used to feed a "diamond hard RT" PCI card's buffer
[02:04:15] <zwelch> where my knowledge ends is at the D/A boundary
[02:04:41] <zwelch> i.e. what components other than a FPGA do we drop on the card? external connectors?
[02:04:49] <les> Well , ok. But f=ma is deterministic.
[02:04:53] <zwelch> unfortunately, that's where the real costs begin
[02:04:55] <les> just a thought.
[02:05:48] <zwelch> * zwelch hopes paul_c is following along with his thoughts
[02:06:55] <paul_c> offload the realtime tasks on to dedicated DSP type cards, you don't need a GP RT OS
[02:07:11] <les> The whole premise I think of emc was to use a gp commodity's power to do high performance motion control rather that push pixels and stuff.
[02:07:14] <zwelch> well, but we're trying to reduce cost, right?
[02:07:29] <paul_c> double buffer the data in a deep enough fifo, problems disappear.
[02:07:58] <les> proprietary machine control software is very expensive, yes
[02:08:26] <jepler> but if you're going to do a high-end servo system the cost of the PC gets relatively smaller
[02:08:41] <paul_c> les: QUALITY machine control pacjages are expensive.
[02:08:51] <jepler> if you're going to do a stepper system (open loop) then all you need is hardware to "clock out" step waveforms you calculate ahead of time in dumb userspace
[02:08:55] <zwelch> yeah, that's true regardless :)
[02:08:59] <les> buffering is an answer...because a motion control program is really detertministic
[02:09:06] <les> oops
[02:09:12] <les> sp
[02:09:42] <les> the only nhon deterministic thing is cutting forces
[02:10:00] <les> non
[02:10:33] <paul_c> with realtime processing, you can do adaptive machining..
[02:10:43] <les> yes
[02:11:50] <les> hard RT is really all about the unknown....if things are known you don't need it!
[02:12:47] <les> lots of things in machining are already known.
[02:13:21] <les> not all
[02:13:24] <les> but lots
[02:15:52] <paul_c> gotta go.
[02:16:37] <les> bedtime for paul!
[02:17:03] <les> gosh 1 am over there.
[02:19:14] <les> well anyway...zwelch...geting late even on the right coast
[02:19:21] <les> good night!
[02:20:39] <Jymmm> night les
[02:21:14] <les> to the music rom ...night jymmm.
[02:21:22] <Jymmm> =)
[02:21:47] <Jymmm> les is that nect to the stil room?
[02:22:00] <Jymmm> next
[02:57:07] <CIA-8> 03zwelch 07auto_configure_0_2 * 10emc2/ (193 files in 21 dirs): Merge auto_configure_0_2 branch with HEAD in prep for further branch work.
[02:57:15] <CIA-8> 03zwelch 07auto_configure_0_2 * 10emc2/ (167 files in 25 dirs): Merge auto_configure_0_2 branch with HEAD in prep for further branch work.
[03:05:06] <zwelch> * zwelch eyes CIA-8 wearily
[03:22:13] <Jymmm> lol
[03:22:27] <Jymmm> you got narked off =)
[21:16:19] <les> calculus was invented to make this stuff easy to describe
[21:16:21] <Jymmm> the last illustration is starting to make sense to me...
http://hyperphysics.phy-astr.gsu.edu/hbase/cf.html#cf2
[21:17:01] <les> yes that is a graphical proof...like the greeks did
[21:17:35] <les> it's a vector velocity sum
[21:17:42] <les> and difference
[21:18:20] <les> see how centripedal accel always points to the center of rotation
[21:18:54] <Jymmm> the 1st red arrow?
[21:19:04] <Jymmm> DeltaV
[21:19:14] <les> this will always be true unless there is also tangiential acceleration
[21:19:28] <les> yes deltav
[21:20:31] <Jymmm> *****
[21:20:59] <les> invalid password_try again
[21:21:27] <Jymmm> heh... no I do that to create a 'flag' in my log files for later searching.
[21:21:37] <les> ah
[21:21:40] <les> heh
[21:22:11] <les> cnc paths are typically a mixture of centripedal and tangiential acceleration
[21:22:14] <Jymmm> I have irc logs that go back like 6 years.
[21:22:24] <les> like starting an arc from a standstill
[21:22:31] <les> wow
[21:23:24] <Jymmm> I've gone back a couple years looking for a link sometimes.
[21:24:45] <Jymmm> les: paul_c talks a lot so sometimes I have to reread what he's said like 4 or 5 times to get it =)
[21:24:57] <Jymmm> * Jymmm ducks!
[21:25:25] <Jymmm> les thanks for the physics 101 =)
[21:25:37] <les> haha yw
[21:26:01] <les> try talking to Fred Proctor some time!
[21:26:20] <Jymmm> oh hell no! he's a nerd with a slide rule!
[21:26:30] <les> smart.
[21:26:34] <les> too smart.
[21:26:38] <les> heh
[21:26:59] <Jymmm> probably a electronic slide rule at that! =)
[21:27:55] <les> He thinks in quaternions and jacobeans
[21:28:05] <les> come to think of it...so do I.
[21:28:36] <Jymmm> * Jymmm thinks in terms of Jerry Springer
[21:28:42] <les> haha
[21:28:57] <paul_c> Jymmm: You need to listen carefully - The Brit accent can be a little difficult fer furriners sometimes ;)
[21:29:23] <Jymmm> paul_c It's not your accent
[21:29:29] <les> hilbilies can understand you fine paul...
[21:29:35] <Jymmm> rotf
[21:29:43] <les> really
[21:29:51] <les> haha
[21:29:59] <Jacky^> what if clicking more time + on the gui the motor turn sometime left, sometime right ? O_O
[21:30:09] <Jacky^> parport died ?
[21:31:16] <les> steppers might go backward if they hit a mid band resonance
[21:32:22] <Jacky^> it seem to me, another parport burned..
[21:33:46] <les> oh no
[21:34:19] <les> must be really drawing a load?
[21:34:48] <les> optos trying to sink too much current?
[21:36:05] <Jacky^> les clicking to move the axis X turn random
[21:36:21] <Jacky^> optos circuit should be ok ..
[21:36:32] <Jacky^> i bought 6n137
[21:36:58] <Jacky^> limit switches are disconnected at the moment
[21:37:05] <les> you checked that a parport can source enough current to drive the led?
[21:37:06] <Jacky^> no clue ..
[21:37:21] <Jacky^> les: nope..
[21:37:38] <Jacky^> but it worked yestarday and all the day, today ..
[21:37:44] <Jymmm> Jacky^ it sound slike you are overdriving somethign somewhere or you have a defective component. you're loosing steps, have a hot stepper, and now no para port
[21:37:46] <les> I don't remember exactly how much a parport can source
[21:38:30] <Jymmm> I was told parport can sink better than it can source.
[21:39:05] <Jacky^> this the third i burned..
[21:39:07] <Jacky^> damn
[21:39:31] <Jymmm> * Jymmm thinks Jacky^ need to learn the art of overengineering
[21:39:55] <les> 2.6 ma...I looked it up
[21:40:02] <les> that's at 2.4v
[21:40:07] <Jymmm> and BEMF?
[21:40:12] <Jacky^> * Jacky^ jacky think to buy commercial driver and leave to do the hacker..
[21:40:34] <les> let me look up 6n137
[21:41:06] <Jacky^> les, i already have the schematic online
[21:41:21] <Jacky^> and pcb maded with eagle
[21:41:29] <Jacky^> it took to me a lot of time :\
[21:41:33] <Jacky^> wait..
[21:42:10] <les> I read specified current for 6n137 is 5 ma
[21:42:18] <les> might fry parport
[21:42:46] <cradek> 5ma base current?
[21:42:48] <les> some might take it but normal max according to one site is 2.6
[21:42:56] <Jacky^> les: here:
http://www.roboitalia.com/modules.php?name=coppermine&file=thumbnails&album=158
[21:43:03] <cradek> you should limit base current with a resistor
[21:43:08] <Jacky^> at the left the schematic i'm using
[21:43:13] <les> not sure chris checking ths spec sheet
[21:43:57] <Jacky^> the driver are L297-298
[21:44:23] <les> listed as "input current"
[21:44:47] <les> if so, that seems a bit high to source from a parport
[21:45:21] <cradek> % units 5V/2350ohm mA
[21:45:30] <cradek> * 2.1276596
[21:46:53] <les> 2.12 would seem fine
[21:47:50] <cradek> with 470 ohm current limiting for the optoisolators (giving about 10mA) you only need a beta of 5
[21:47:56] <les> I guess the faster optos need a good bit of current to charge up the led junction capacitance
[21:48:02] <cradek> I don't see anything wrong with the input side of this design
[21:48:25] <les> let me look
[21:48:33] <cradek> is 10mA enough to drive the optoisolators?
[21:48:38] <Jacky^> infact.. it seem work fine ..
[21:48:57] <Jacky^> i've the lates parport pci
[21:49:05] <cradek> oh, I see you were looking up the optoisolator
[21:49:06] <Jacky^> i burned 1 pci and 2 isa
[21:49:20] <cradek> if so, it specs at 5 mA and you're giving it about 10
[21:49:29] <Jacky^> but linux seem non recognize this card
[21:50:08] <Jacky^> cradek: too much ?
[21:50:14] <Jacky^> 10 ma
[21:50:17] <les> oh...I see the 2n222 driving it...yeah that should be fine
[21:50:33] <les> wonder why parports are frying?
[21:50:41] <Jacky^> :\
[21:50:42] <les> 2n2222
[21:50:44] <les> oops
[21:51:43] <cradek> Jacky^: you would have to check the datasheet to see if 10mA will damage anything
[21:51:54] <cradek> but this does not explain why you are frying parallel ports. I guess there is another problem.
[21:52:07] <les> 2v drop from led and 470....
[21:52:39] <cradek> no, the drop across the led and 470 resistor will be nearly 5v because the transistor is in saturation
[21:52:53] <les> right
[21:53:13] <les> current ought to be about 3/470
[21:53:23] <cradek> oh, I see what you mean
[21:53:33] <cradek> so about 6 or so
[21:53:35] <cradek> sounds fine doesn' tit
[21:53:37] <cradek> doesn't it
[21:53:40] <les> I did assume saturation
[21:53:48] <les> so that is 6.3 ma
[21:54:06] <les> yeah that's in the ballpark...seems fine
[21:54:24] <les> hmm
[21:54:53] <cradek> do you know which parallel port pins are being burned out?
[21:55:23] <Jacky^> cradek: no idea
[21:55:42] <Jacky^> i know that Y axis is jojjing wrong
[21:56:06] <Jacky^> when i click to manually move it
[21:56:12] <Jacky^> other axis are ok
[21:56:28] <Jacky^> so, i think the pin dir Y axis
[21:56:30] <cradek> have you checked for wiring errors, solder bridges, parts inserted wrong?
[21:56:53] <Jacky^> it was working one hour ago ..
[21:57:08] <Jacky^> latest time i haved this issue was the parport
[21:57:22] <Jacky^> i would like to try with another parport to be sure
[21:57:25] <les> the same thing happened twice?
[21:57:33] <Jacky^> the latest .. i've is this:
[21:57:33] <les> so far?
[21:57:37] <Jacky^> http://www.qtec.info/products/product.htm?artnr=12886
[21:57:55] <Jacky^> but i don't know if there's a driver for linux
[21:58:18] <Jacky^> les: same thing ..
[21:58:37] <Jacky^> the card i burned where isa
[21:58:46] <Jacky^> cards*
[21:59:31] <les> well I don't see any unreasonable currents in your schematic
[21:59:42] <les> all resistors are fairly high
[21:59:51] <AchiestDragon> hmm
[22:00:02] <les> the 470 for the opto is the lowest
[22:00:12] <les> and seems fine for a 2n2222
[22:00:30] <AchiestDragon> on your pcb layout is the blue layer top or the red
[22:00:50] <Jacky^> hi AchiestDragon yeah, double side
[22:00:58] <Jacky^> blu bottom, red top
[22:01:30] <les> partial short to ground on one of the data pins is all I can think of
[22:01:32] <Jacky^> i'm sure is the parport
[22:01:53] <les> like Cris said...solder bridges etc
[22:01:58] <les> chris
[22:02:15] <AchiestDragon> yes sounds to be something like that
[22:02:18] <Jacky^> :(
[22:03:07] <les> well, just get your magnifiers!
[22:03:26] <AchiestDragon> there looks to be a tracking error
[22:03:39] <les> did you do leaded or surface mount?
[22:04:07] <AchiestDragon> pin 2 has no connection and pin 3 has one on both sides
[22:04:18] <les> ah
[22:04:29] <les> I don't have the pcb layout
[22:04:32] <AchiestDragon> pin 1 rather
[22:04:42] <AchiestDragon> http://www.roboitalia.com/modules.php?name=coppermine&file=displayimagepopup&pid=1322&fullsize=1
[22:05:09] <Jacky^> AchiestDragon: i know about pin 2
[22:05:22] <Jacky^> i manually repaired them ..
[22:05:38] <les> got it
[22:06:24] <Jacky^> infact pin 2 is X dir and work ..
[22:07:21] <Jacky^> also some 5V line was missing ..
[22:07:28] <AchiestDragon> its hard to read with the fonts , but the net pin accross form it
[22:07:41] <Jacky^> but i tested it with the scope before insert
[22:07:57] <Jacky^> all input and all output working
[22:08:07] <AchiestDragon> so the red layer is the same as the components ?
[22:08:35] <AchiestDragon> same side
[22:08:41] <Jacky^> yeah
[22:08:44] <Jacky^> top side
[22:09:02] <AchiestDragon> k
[22:10:54] <AchiestDragon> ok check the resistors are not phisicaly tuching eachother ( the coting can be iffy on some and if so if thay tuch a track under them or the one next to it it can act like a short
[22:10:59] <AchiestDragon> coating
[22:11:46] <les> one place I sometimes find cold/ bad solder joints is component leads used for through holes
[22:11:57] <les> through connections
[22:12:28] <Jacky^> i know
[22:12:29] <AchiestDragon> did you etch the board yourself
[22:12:56] <Jacky^> it was hard to get the pcb singleside
[22:14:37] <Jacky^> let me check if this sun1888 chipset parport is uspported..
[22:14:41] <Jacky^> i wnat to try
[22:15:26] <AchiestDragon> if so , did you use wire wool to clean of the etch resist, wire wool can leave fine splinters that short things out ,
[22:16:34] <Jacky^> AchiestDragon: ok, i'll check it
[22:16:52] <AchiestDragon> i would get a meter with the circuit unplugged and the meter on resistance scale , check each input for its resistance to the 5v and ground pins
[22:17:31] <les> about the only part that could fry the parport signal line is the connections of the 2n2222 and the two 4k7 resistors
[22:18:23] <les> the traces around those
[22:20:15] <les> heck you would only be at 2 ma even if the base was a direct short
[22:20:40] <les> the 4k7s to the left...
[22:21:34] <AchiestDragon> think its more likely to be in the cable or close to where the parallel cable connects to the pcb
[22:21:50] <les> that could be
[22:23:08] <AchiestDragon> i would of mounted a 25way dtype connector on the pcb or the normal printer centronics connector then it would save me having to wire it in manaulay
[22:24:23] <les> yeah
[22:25:24] <les> Jacky might want to measure the voltage drop across thr 4k7s
[22:25:49] <les> sum/4700 < 2.6 ma
[22:27:23] <AchiestDragon> its about 1ma at 5v , and less lower
[22:28:11] <les> that would be fine if that is measured
[22:28:25] <Jacky^> les: ok
[22:28:42] <Jacky^> the latest parport seem to be recognized !
[22:28:56] <Jacky^> 0xb400 ..
[22:29:15] <Jacky^> but theres some irq prob ..
[22:29:29] <Jacky^> nic card ant network wont work ..
[22:29:38] <Jacky^> let me check if this parport work
[22:29:45] <Jacky^> came back in 5 min
[22:30:07] <les> well I have to go mow some...I will check back! good luck
[22:31:22] <Jacky^> les: thanks :)
[22:31:41] <les> yw...cannot be much help over irc heh
[22:32:08] <AchiestDragon> Jacky^: the 7408 worked then
[22:35:08] <Jacky^> ouch :\
[22:35:25] <AchiestDragon> what
[22:35:27] <Jacky^> if also this parport is not burned
[22:35:35] <Jacky^> the prob is not in the parport !
[22:35:42] <Jacky^> same thing ..
[22:35:47] <AchiestDragon> k
[22:36:10] <Jacky^> i go to change the L297 ..
[22:36:14] <Jacky^> is in a socket
[22:54:08] <Jacky^> ok
[22:54:22] <Jacky^> L298 burned in Y board ..
[23:01:07] <Jacky^> oh.. wel
[23:01:12] <Jacky^> 297 too ..
[23:01:20] <Jacky^> and a diode in short ..
[23:04:42] <AchiestDragon> so your parallel ports are ok ?
[23:07:18] <Jacky^> I think so
[23:07:32] <Jacky^> the prob is in the driver ..
[23:09:37] <icee> jacky: what boards are you using?
[23:20:45] <Jacky^> icee: l297-298
[23:21:04] <icee> i know the ST micro ICs.. did you build your own boards?
[23:21:23] <Jacky^> http://www.yty.net/cnc/Steppermotordriver.pdf
[23:30:44] <paul_c> Good old Henry...
[23:32:57] <Jacky^> damn young Jacky^ !
[23:33:00] <Jacky^> :D
[23:33:35] <Jacky^> paul_c: I burned all ics and parports i haved..
[23:37:43] <Jacky^> doh
[23:38:00] <paul_c> Add a bit of olive oil and season to taste.
[23:38:04] <Jacky^> 1 ohm 4 w resistor interrupted
[23:38:16] <Jacky^> first time i see ..
[23:38:18] <Jacky^> O_O
[23:38:30] <Jacky^> strange things are happening here
[23:38:40] <paul_c> * paul_c gets an invite to contribute some "stuff" to RTAI..
[23:44:54] <icee> jacky: the design looks fine.. not sure why you'd be having so much bad luck with burning it up
[23:44:59] <les> oh really paul
[23:45:02] <les> cool
[23:47:41] <paul_c> more work for me if they want a maintainer for the stuff...
[23:48:01] <les> yeah
[23:50:02] <Jacky^> icee: I know.. but i never seen a resistor of 4W insulated !
[23:50:11] <Jacky^> very strange..
[23:50:33] <Jacky^> the driver is supplied with 32 V
[23:50:48] <les> so parports actually ok jacky? that makes sense
[23:52:17] <les> popping the L298 huh?
[23:52:24] <Jacky^> les: i think so..
[23:52:43] <Jacky^> i changed the L298 and it burned
[23:52:52] <Jacky^> of course the 297 too ..
[23:52:57] <les> ok that is a clue
[23:53:10] <Jacky^> after, I found a resistor interrupted, 1 ohm 4 w
[23:53:19] <les> oooh
[23:53:31] <Jacky^> sound strange ..
[23:53:47] <paul_c> Max V is 46V, so 32V is well below that...
[23:53:57] <Jacky^> paul_c: yeah
[23:54:06] <Jacky^> Voltage should be ok, 32 V
[23:54:11] <les> ok
[23:54:16] <icee> jacky: you don't have an open / problem on the vref line do you?
[23:54:20] <paul_c> Might be inclined to put a crowbar across the power rails though
[23:54:31] <paul_c> just to catch any spikes.
[23:54:44] <les> I do
[23:54:51] <Jacky^> icee: no..
[23:55:21] <Jacky^> PS should be ok
[23:55:32] <Jacky^> the other dribers are working with the same PS
[23:55:40] <Jacky^> driver*
[23:55:51] <icee> jacky: no solder bridges or anything on your in lines, are there?
[23:56:06] <icee> or problems on SA/SB to L297
[23:56:09] <Jacky^> you mean in the driver board ?
[23:56:13] <icee> yah
[23:56:33] <Jacky^> yes, there are some bridges
[23:56:50] <Jacky^> but it seem ok
[23:57:03] <Jacky^> i checked with ohmeter
[23:57:17] <Jacky^> i checked all components on the board
[23:57:22] <Jacky^> are few components
[23:57:47] <icee> yah..
[23:58:00] <icee> but an open on one of the sense lines, etc, can be very bad and cause what you're describing
[23:58:20] <Jacky^> uhmm
[23:58:24] <Jacky^> :(
[23:58:41] <Jacky^> for this evening i burned a couple of L ics
[23:58:42] <alex_joni> hello
[23:58:52] <Jacky^> i'm going to turn on again ..
[23:59:03] <Jacky^> the night is not finished yet :\
[23:59:18] <Jacky^> if i'm lucky i could burn some other thing yet..
[23:59:21] <paul_c> * paul_c burned dinner again
[23:59:25] <Jacky^> hello alex_joni :)
[23:59:29] <paul_c> Jacky^: You are not alone.
[23:59:38] <alex_joni> paul_c: what were you trying to cook?
[23:59:47] <paul_c> pasta (I think)
[23:59:47] <Jacky^> paul_c: thanks
[23:59:51] <alex_joni> heh