Back
[00:00:00] <pigi> If I move the X axis I get 00000010 00000000
[00:00:29] <pigi> which seems to be correct, but the docs says that the X pins are 2 and 3 ...
[00:00:47] <pigi> so everithing seems to be shifted by 1 bit.
[00:00:51] <paul_c> Pins 2 & 3 on the DB25 connector
[00:01:47] <pigi> so the outb pull on the 2 pin if I ask for first bit ?
[00:02:19] <paul_c> yes - D0 is on pin2 of the DB25
[00:03:30] <pigi> Ok, that is important. D0 has to be intended as Digital_IO port and is corresponding with pin 2.
[00:03:56] <paul_c> I've added the old freqfunc code which is a little easier to understand - You'd need to do an update...
[00:04:24] <pigi> I'll do it tonite, but I think that this one is enough clear.
[00:04:39] <paul_c> The Docs can lead to some confusion
[00:04:45] <pigi> Actually I'm on work, and can't reach the internet directly....
[00:05:03] <paul_c> The ini files use INDEX, but the docs refer to "Pins"
[00:05:37] <paul_c> INDEX is the same as D0-D7 for the first byte
[00:06:06] <paul_c> but the "Pins" in the docs refer to the DB25 connector on a parallel port.
[00:06:07] <pigi> I think the cocs are allrigth. It's that I have no knowledge of parallel port writing.
[00:06:13] <pigi> s/cocs/docs
[00:07:04] <paul_c> I'll add some comments to the code to clarify it.
[00:08:00] <pigi> The other question is: howmuch the timing is important when writing to the parallel ?
[00:09:11] <paul_c> Each read or write takes between one to two microSeconds
[00:09:27] <pigi> Ok.
[00:09:57] <pigi> My idea was actually ( just for test ) to add a wrapper to extDioByteWrite
[00:10:34] <pigi> that read the original low/hibyte and
[00:10:54] <pigi> convert to the others pin. So the cycle wont be changed
[00:11:21] <pigi> but I can have different output based on what the wrapper decide that have to be done
[00:12:11] <pigi> Obviously this wrapper will add some delay in cycle, that should be always the same, but it's different than write directly to port
[00:12:25] <paul_c> That would work - It would be better to do it in freqfunc...
[00:13:53] <pigi> Do you mean where the code plays with those nice XOR and other, or the wrapper should be a function inside the freqfunc ?
[00:13:58] <paul_c> The delay from a modified extDioByteWrite would be small
[00:14:53] <pigi> I have not too much confidence with shifting bit, so the transation table would be easier for me.
[00:14:55] <paul_c> Were the output byte is assembled would be the best place (in my opinion).
[00:16:08] <pigi> and moreover, everything in the phase where the output byte is assembled is heavly based on concept that the bit are consequently ( D0 D1 for X and so on )
[00:17:06] <pigi> if I found a board that has not this sequence of bit, I suspect that study a function for ANDing or XORing the bit could cause problems ( to me at least ;) )
[00:17:45] <pigi> and BTW I will do this only for study. It could be ameliored later.
[00:18:01] <paul_c> A lookup table for the Bit definitions would require a re-think on how the byte is assembled
[00:18:57] <pigi> Not necessary. If the byte is assembled always in the same way, you have a costant ( the assembled byte )
[00:19:02] <paul_c> but C does have some tricks that allows for bit manipulation that should make the task easier
[00:19:51] <pigi> then when you read the configuration file, that define where the D0 should map, you have the translation table
[00:19:56] <paul_c> Why waste time assembling a byte if it is going to be translated elsewhere ?
[00:21:37] <pigi> I do agree with you, but ( for me at least ) would be a pain in modifying the assembling routine and all the others control that are int his area, at the moment
[00:21:59] <pigi> while using a wrapper would be question of few minutes.
[00:22:07] <paul_c> Translation in extDioByteWrite only works if all four steppers are on the same port byte
[00:22:27] <pigi> this is what I was thinking
[00:22:29] <paul_c> If you have six steppers
[00:22:49] <paul_c> or want to spread four across two bytes
[00:23:44] <pigi> you should always work on the assembling routine. My idea was instead to abstract myself from where you "put" the steppers.
[00:24:45] <pigi> the program works in the usual way. The translation routine spread the signals wherever the should be according with a configuration file
[00:25:10] <pigi> so no modify to other parts of code should be done. Well, almost
[00:26:24] <pigi> obviously there should be a wrapper also around the "read" routine tho translate the input ( lim or whatever ) into what the program thinks that there should be an input.
[00:26:39] <pigi> You can see this as a sort of HAL, if you want
[00:26:43] <paul_c> Just for fun - What if you wanted to use D6 & D8 to turn the spindle on/off ?
[00:27:09] <paul_c> (read D6 & D&)
[00:27:14] <paul_c> (read D6 & D7)
[00:28:30] <pigi> Noproblem. The wrapper should have enough information to "remap" this from the actual position in assembled byte, to the new mapped position
[00:29:16] <pigi> and btw this signal are used only on 2nd parallel ( if I good remember )
[00:30:17] <paul_c> There are instructions for turning bits on/off on the first parallel port - Used for lasers for example
[00:31:09] <pigi> so three way: first way is to have a wrapper that have all the info on output bytes and tha whole mapping table from config file. Second way to work only on first parallel.
[00:31:59] <pigi> I can't find this in docs, but if the wrapper is enough intelligent, you can have everithing ther.
[00:33:01] <pigi> third ( and last way ) to create a new module ( say freqpigi eheheh ) that works only for this kind of simple devices, with few input and few output.
[00:34:08] <paul_c> I think it a choice of where the byte should be assembled...
[00:34:50] <paul_c> In the wrapper is one place...
[00:35:03] <pigi> It's really more elegant, where the byte is assembled, but the problems are the sames.
[00:35:05] <paul_c> or in freqpigi()
[00:35:09] <pigi> eheheh
[00:35:52] <paul_c> It is just in the details of how the information is passed to the assembly routine
[00:36:46] <pigi> sure. There is ever my problem in playing with "~ | &" symbols :)
[00:36:47] <paul_c> let me add some comments to the stepper code, and you can comment on them this evening.
[00:36:58] <pigi> ok. I will be glad
[00:37:30] <pigi> ( that's why I love opensources )
[00:37:59] <pigi> there is always something to learn, and to comment :)
[00:42:36] <alex_joni> paul_c: seen your mail to devel
[00:56:39] <pigi> * pigi goes back to work. See ya later
[00:59:51] <cradek> am I supposed to be able to run sim.run without realtime? it looks like it works except it won't run a program
[01:00:04] <alex_joni> did you get out of e-stop?
[01:00:07] <cradek> yes
[01:00:13] <alex_joni> did you home your axes?
[01:00:15] <cradek> (emc1)
[01:00:19] <cradek> no
[01:00:32] <alex_joni> well... you gotta do that in order to run a program
[01:00:35] <cradek> aha
[01:00:43] <alex_joni> but... (I tried to home them, and it worked)
[01:00:50] <alex_joni> if I tried to jog them... it failed
[01:00:57] <alex_joni> I got an following error...
[01:00:59] <alex_joni> :(
[01:01:32] <cradek> still doesn't seem to work for me
[01:01:38] <cradek> Issuing EMC_TASK_PLAN_RUN -- (+507,+16, +13, +0,)
[01:01:38] <cradek> emcTaskPlanRead() returned 0
[01:01:38] <cradek> emcTaskPlanLine() returned 1
[01:01:38] <cradek> emcTaskPlanCommand() called. (line_number=1)
[01:01:38] <cradek> canterp: unrecognized canonical command
[01:01:41] <cradek> emcTaskPlanExecute(0) return 1
[01:01:41] <cradek> emcTaskPlanClose() called at emctaskmain.cc:1248
[01:01:44] <cradek> Issuing EMC_TASK_PLAN_SYNCH -- (+516,+12, +0,)
[01:01:46] <cradek> emcTaskPlanSynch() returned 0
[01:01:49] <cradek> I get those when I hit Run
[01:02:41] <alex_joni> well... try jogging first (in Manual mode)
[01:02:46] <alex_joni> to ensure that emc is working
[01:02:56] <alex_joni> * alex_joni remembers it didn't for him...
[01:03:05] <cradek> it moves .2" then following error
[01:03:15] <alex_joni> yup.. that means something is fishy
[01:04:15] <alex_joni> and probably that's why the RUN isn't running ... ;)
[01:04:31] <alex_joni> I managed to get it to run with generic.run (stepper setup)
[01:04:43] <cradek> without realtime kernel?
[01:04:46] <alex_joni> and emcplot3d -ini generic.ini
[01:04:50] <alex_joni> with realtime kernel...
[01:05:09] <alex_joni> gotta look at sim.run why it's not working...
[01:05:30] <alex_joni> but last night I was pretty tired, and had no urge to do that...
[01:06:37] <alex_joni> don't promise I'll get to take a look at it today... but I'll have it in mind...
[01:07:40] <cradek> but I am supposed to be able to use sim without realtime kernel?
[01:07:47] <alex_joni> yup... surely
[01:08:37] <alex_joni> * alex_joni is looking at sim.ini...
[01:08:46] <alex_joni> every part of it is stated as nonrealtime
[01:08:57] <alex_joni> so it should work without realtime kernel
[01:09:40] <cradek> huh, I can jog Y and Z but not X
[01:10:32] <alex_joni> maybe it's not set up right
[01:10:37] <alex_joni> FERROR, MIN_FERROR & such
[01:11:16] <cradek> it has P=1000 and the others have P=1
[01:12:50] <cradek> with P=1 now I can jog all 3 axis
[01:12:55] <cradek> but it still won't run my program
[01:13:13] <cradek> also MDI does not work
[01:15:11] <cradek> changing to minimilltask fixes it
[01:15:11] <alex_joni> hmmm... strange
[01:15:15] <alex_joni> I see...
[01:15:29] <cradek> works fine with those two changes
[01:18:44] <cradek> wonder if I should check them in
[01:18:55] <cradek> probably so, because it was clearly broken
[01:20:23] <paul_c> Go for it - It looks Like Fred Proctor had been using sim.ini for some testing...
[01:22:36] <CIA-9> 03cradek * 10emc/sim.ini: fix two errors: following error on X axis, broken AUTO and MDI
[01:23:19] <cradek> sim.run and emcplot3d in live mode work together nicely without realtime
[01:31:30] <les> argh I called on that Bridgeport cnc and it is in perfect running shape...like new and...
[01:31:49] <paul_c> sold ?
[01:31:50] <les> The tarp had blown off of it and it is now sitting in the rain
[01:32:02] <les> geez
[01:32:17] <les> Looks like brand new I am told
[01:32:25] <les> it's scrap iron now
[01:33:00] <paul_c> Might still be OK as long as no water is left sitting in the spindle/head
[01:33:45] <les> well I am having someone go over and prplace the tarp and blast it with rust preventative
[01:33:52] <les> but prob too late
[01:34:03] <les> It has been raining for 3 days
[01:34:10] <paul_c> offer $5 per ton for scrap
[01:34:26] <les> that is about the size of it
[01:34:40] <les> guy just trashed a kilobuck or so
[01:34:47] <les> what an idiot
[01:35:46] <les> oh well back to hand soldering up usb connectors here
[01:36:39] <cradek> Error 1 in sqRunCycle
[01:36:39] <cradek> Panic: length negative in sqPlanSegment
[01:36:58] <cradek> I keep getting these in sim
[01:38:44] <paul_c> Switch to emcmotsim rather than emcsegmotsim
[01:58:14] <alex_joni> * alex_joni is gone home
[03:11:09] <paul_c> Evening Ray.
[03:25:40] <rayh> Hi Paul
[07:41:00] <paul_c> Hi ottos
[07:41:39] <ottos> hi
[07:43:41] <ottos> anything new in the emc community?
[07:44:10] <paul_c> Trying to decipher sme changes someone has submitted
[07:45:34] <ottos> does anyone know if someone has implemented a toolchanger with emc?
[07:47:30] <paul_c> nope - Not heard of anyone
[07:47:41] <paul_c> But that doesn't mean it can't be done.
[07:48:41] <Pigi> Ciao all
[07:49:03] <paul_c> What Ho
[07:49:32] <ottos> I'm thinking of giving it a try..
[07:55:50] <ottos> ok back to work...later..
[08:02:21] <Pigi> paul_c: I have reread our discussion this afternoon,and I found another good reasonfor work with translation tables...
[08:02:39] <paul_c> Hmmm...
[08:03:59] <Pigi> Apart for all, what will happen if the basic three axis are spread on two byte ?
[08:04:53] <paul_c> That is something that you want to avoid
[08:05:00] <paul_c> For example
[08:05:23] <Pigi> I'm almost sure I want to avoid, but what for people projecting their boards ?
[08:05:29] <paul_c> If Z axis step is on Byte 0, Bit 7
[08:05:46] <paul_c> and the Z Dir is Byte 1, Bit 0
[08:06:07] <paul_c> Step will change 2uSec before Dir.
[08:06:51] <Pigi> right. but what if X and Y are on byte 0 and Z ( both signal ) on byte 1 ?
[08:07:36] <Pigi> that what I mean.... I'm sure that some basic rule must be given, but this is a case that could exist ..
[08:07:43] <paul_c> A 2uSec delay is reasonable
[08:08:36] <Pigi> Sure. In my idea, abstracting the logical layer, from physical one would keep the good job done until now,
[08:09:03] <cradek> if you must split across two ports I think you should put all DIR on one port and all STEP on the other
[08:09:22] <cradek> then STEP can happen simultaneously on whatever axes necessary
[08:09:40] <Pigi> Nono, std by. I will try to explain better.
[08:09:48] <cradek> timing between DIR and STEP is unimportant except that there is a minimum time necessary
[08:10:26] <Pigi> it's alway fault of my bad english
[08:10:53] <cradek> our italian would be worse
[08:11:42] <Pigi> In the logical layer the program keep on work with byte 0 for x y z and byte 1 for a b c. Thus all the cycle keep working thinking that the byte are in this way.
[08:11:56] <Pigi> No change should be done in no part of code, nowhere.
[08:13:05] <Pigi> when the bit should be sent out ( really ) the the translation routine do the job, converting the "logical" byte into phisical ones JUST for the output
[08:14:06] <Pigi> same would be for the input. The routine read from the port, then convert the input signal into what the program consider input.
[08:14:59] <Pigi> this would give the maximum flexibility toward the boards, keeping the current work working
[08:15:06] <Pigi> ( hope it is clear )
[08:15:53] <cradek> I understand HAL in emc2 does this separation between logical and physical, allowing any mapping between them
[08:16:09] <cradek> but I am no expert about it
[08:16:41] <Pigi> I've not seen the emc2 code ( nor docs ) up to now ... :)
[08:16:46] <Pigi> my fault.
[08:17:12] <Pigi> paul_c: I think you don't agree with me ... right ?
[08:21:37] <paul_c> I'm not bothered where the byte is assembled
[08:21:50] <paul_c> as long as it is done right, and quickly.
[08:22:09] <Pigi> eheheh. I agree also on this.
[08:23:01] <Pigi> But, being the last buy that do some works on this project, I will be happy if the others agree.
[08:23:18] <Pigi> That's not my code, al least it could be my patch :)
[08:25:10] <paul_c> Did you do an update ?
[08:25:39] <Pigi> right now
[08:26:34] <Pigi> I can see the #if 1 ddition
[08:26:42] <Pigi> s/ddition/addition
[08:28:57] <paul_c> Needs padding out a bit more...
[08:32:59] <Pigi> what can clarify my doubt, actually is to understand what exactly happen between line 271 and 302.
[08:33:11] <Pigi> Here is where the byte are assebled.
[08:34:03] <Pigi> s/assebled/assembled
[08:35:34] <Pigi> or better, at line 244, 252, 272 and 286 ( as I can understand easly the other 4 assembly, deriving from this )
[08:36:46] <Pigi> here is where I ( we ) should work over, because after this there is only the call to extDioByteWrite([lo hi]byte)
[08:37:21] <paul_c> yup - And the bytes need to be assembled befor the call is made
[08:37:50] <paul_c> extDioByteWrite can be called from other places
[08:39:36] <Pigi> sure. Have I been able to explain why I wouldn't work over the lines that I told before ?
[08:39:43] <Pigi> they are working correctly.
[08:40:00] <Pigi> and I'm frigthen to modify it .
[08:40:13] <Pigi> But with a little of calm it could be done there.
[08:41:12] <Pigi> but I suspect thet the code would not be so clean ( read polite )
[08:42:21] <paul_c> Check it out, modify, and either a) send me a diff, or b) commit the changes.
[08:43:06] <Pigi> I will make some modify with comments, ( after that I have found where to read the config files ) and the I will send it to you.
[08:44:07] <Pigi> You can decide the if they are ok and if you agree you can commit it. At least I can create a new fremod, as we told today, and use this last one for my needs
[08:44:47] <Pigi> s/the if/then if
[08:47:28] <paul_c> No problem.
[08:49:05] <Pigi> do you have a quick pointer to some variable that is read from the configs file and used in (whatever*.c) in emcmot ?
[08:49:31] <Pigi> emcmotCommand could be ?
[08:49:43] <paul_c> You don't want to go there
[08:50:28] <paul_c> OUTPUT_SCALE for example
[08:51:24] <Pigi> OUTPUT_SCALE could be ok for me. It's only to copy some snippet and use it as example for what I need to read from config file ( the output bits ).
[08:53:28] <Pigi> the config files are read in emcio, isnt'it ?
[08:53:57] <paul_c> Some are...
[08:54:30] <paul_c> Look at iniaxis.cc first
[08:54:38] <Pigi> ok
[08:55:20] <paul_c> An easier one to trace might be setup_time
[08:55:40] <paul_c> in the ini file - SETUP_TIME
[08:56:32] <Pigi> ok. nice.
[09:01:58] <Pigi> and btw after reading you "write" in emcmotCommand right ?
[09:05:51] <Pigi> yes, It's the struct used to pass values to the modules.
[09:07:05] <paul_c> There are better ways of passing configuration data
[09:08:55] <Pigi> do you mind explain me a bit ? ( I can also read trough all the code, but it will take some time :) )
[09:10:12] <Pigi> My idea actually is to create a new config section to store the output/input bit ...
[09:10:28] <paul_c> Currently, Configuration data (OUTPUT_SCALE, SETUP_TIME, etc) are all passed via emcmotStruct
[09:11:04] <Pigi> ok.
[09:11:15] <paul_c> The code that handles the read/write of emcmotStruct is in usrmotinttf.c
[09:12:01] <paul_c> The problem here is the realtime code must be running to allow the data to be read and acknowledged
[09:13:14] <Pigi> because some rt primitive are used for this ?
[09:13:15] <paul_c> yet the kernel already has a mechanism for passing data to/from usr space that does not require a realtime task to be running.
[09:16:04] <Pigi> but that would be really "invasive" at the moment.
[09:16:57] <paul_c> yup
[09:18:30] <Pigi> I will google for a bit tomorrow, to see if it would really be invasive, and in case it isn't I will go in this direction, otherwise I will remain on actual line,
[09:18:48] <Pigi> to keep short time for other mods.
[09:19:02] <paul_c> It does require some major changes...
[09:19:43] <paul_c> But once the core interface is in place
[09:19:57] <paul_c> little bits at a time can be converted.
[09:20:30] <Pigi> it seems that for this it should be used a /proc file
[09:22:05] <paul_c> a proc entry should ONLY be used for trivial minor data passing to a kernel module
[09:22:34] <paul_c> echo 7 > /proc/foo/debug
[09:23:30] <Pigi> it was the first answer on my googling activity.
[09:25:24] <paul_c> google for ioctl interface
[09:25:37] <paul_c> and devfs entries
[09:29:08] <Pigi> there is almost a world. Nice infos are on tlpd. "The Linux Kernel Module Programming Guide" eheheh
[09:29:23] <Pigi> well. Sleep time now.
[09:30:19] <Pigi> I have enough information for now.
[09:30:31] <Pigi> later all
[09:41:48] <asdfqwega> What was Pigi working on?
[09:42:08] <asdfqwega> A parport configuration for emc1?
[09:43:05] <asdfqwega> My backlog doesn't scroll up that far :P
[09:50:42] <paul_c> In part, yes.
[10:59:43] <paul_c> Yo daryl
[10:59:54] <daryl> Hey Paul.
[11:04:29] <paul_c> back in ten.
[11:18:32] <cradek> asdfqwega: my parport is wired funny, but I just changed a few lines and recompiled
[11:18:39] <cradek> I think Pigi is making it way way too hard
[11:22:23] <paul_c> Pigi wat's something that is configurable without having to recompile.
[11:22:39] <cradek> I understand; that's an honorable goal.
[11:24:14] <paul_c> I have some ideas on implimentation
[11:24:16] <cradek> I can't think of a good way to make it configurable without making a score of new config variables
[11:24:31] <cradek> IMO none of it's hard except the config file part
[11:25:11] <paul_c> if each axis section has a STEP_INDEX & DIR_INDEX
[11:25:17] <paul_c> (Hi Ray)
[11:25:29] <rayh> Hi Paul
[11:25:33] <paul_c> that would cover most needs...
[11:26:10] <cradek> assuming they are all on the same port, yes
[11:26:31] <rayh> What we talking about? Flipping signal polarity?
[11:26:36] <paul_c> YEHHAA.... anaconda boots !!!
[11:27:08] <rayh> Fantastic. What were you using for packages?
[11:27:15] <paul_c> User configurable step/dir pinouts for EMC
[11:27:40] <rayh> Oh. Okay.
[11:27:41] <paul_c> anaconda with Debian packages.
[11:28:00] <rayh> Which deb?
[11:28:45] <paul_c> This is a deb based replacement for BDI-2.xx
[11:29:25] <rayh> You working from stable, testing, extreme?
[11:29:26] <paul_c> currently have gnome on the CD, but I'll replace that with KDE
[11:29:46] <rayh> That would be great.
[11:30:14] <rayh> The kde that runs with knoppix starts up faster than the kde with morphix.
[11:30:16] <paul_c> * paul_c doesn't like to be right over the bleeding edge - Using Sarge (testing)
[11:30:41] <rayh> I think they paralleled several startup processes.
[11:30:51] <paul_c> Knoppix doesn't have to load 128K (plus) of background
[11:30:54] <rayh> I can live with sarge.
[11:30:56] <asdfqwega> cradek: I don't see multiple ports happenning that often
[11:31:40] <asdfqwega> I would love it, however, if I could squeeze all my I/O needs onto a single parport
[11:31:54] <rayh> Is the file location of stuff like config RH or deb?
[11:32:28] <cradek> asdfqwega: well my maxnc, before I monkeyed it around, had the 4th axis and spindle control on a second parallel port
[11:32:33] <paul_c> Debian
[11:32:42] <cradek> it is (was) a fourphase drive
[11:33:07] <cradek> I think if you're going to bother making the parallel ports configurable, you should support all the drive methods, not only step/dir
[11:33:22] <cradek> (but this suddenly turns into a complex task)
[11:33:42] <paul_c> and also allow for non-parallel port IO cards.
[11:34:16] <cradek> paul_c: that's even harder since they may require setup (8255 type) or some bits inverted or not (parallel port)
[11:34:24] <cradek> paul_c: I don't see how you can do that without writing some C.
[11:34:49] <asdfqwega> cradek: What I've been thinking with what some of developer-speak on here, and all the multiple configs - why not make something live a /dev or /sys virtual filesystem?
[11:35:14] <paul_c> Agreed, but the C should be limited to the extintf.c wrapper.
[11:35:30] <cradek> asdfqwega: I don't follow
[11:36:08] <asdfqwega> Maybe I don't follow either...and I might be off on a tangent
[11:36:34] <cradek> paul_c: it's hard for me to worry about this since C is easier to read and write than any complex config file, but I understand that many machinists don't program.
[11:36:53] <cradek> paul_c: if the system is easy to build, and I know what file to change, I couldn't be happier
[11:37:04] <cradek> paul_c: (neither was true when I started trying to use emc)
[11:37:29] <paul_c> I too find many things easier with a bit of C code
[21:52:48] <CIA-3> 03paul_c * 10emc/src/emcplot3d/emcplot3d.cc: After contacting Jeff Molofee, the licencing of the original code has been clarified - It may be used for non-profit applications.
[22:05:16] <alex_joni> * alex_joni is back
[22:17:56] <alex_joni> paul_c: got your e-mail...
[22:26:17] <paul_c> Yo Alex
[22:26:55] <paul_c> Do you see why I cautioned against a commit ?
[22:49:55] <alex_joni> paul_c: yup, now it all makes sense ;)
[22:50:17] <alex_joni> guess you've been around longer with this stuff...
[22:56:16] <paul_c> Sme of the original code from rcslib/emc was copyright M$
[23:00:56] <alex_joni> M$????
[23:00:58] <alex_joni> wow...
[23:04:25] <alex_joni> any news from zwisk lately?
[23:07:20] <paul_c> nothing new to report
[23:07:53] <alex_joni> * alex_joni wonders what should get done...
[23:08:34] <paul_c> * paul_c needs a Debian rule for EMC...
[23:08:43] <alex_joni> define Debian rule?
[23:09:20] <paul_c> It's the Debian version of a redhat.spec for creating a package
[23:09:35] <alex_joni> I see...
[23:09:48] <alex_joni> * alex_joni knows nothing about spec's or rules...
[23:10:29] <alex_joni> is this for emc only?
[23:10:41] <alex_joni> or does it include the rtai (rtlinux) patched kernel?
[23:10:59] <alex_joni> or a different deb package for that?
[23:12:25] <paul_c> just for emc/rcslib
[23:12:56] <paul_c> cd /usr/bin
[23:15:25] <alex_joni> * alex_joni is reading about dh_make
[23:17:08] <alex_joni> did you know that: " Debian packages never install files beneath /usr/local -- that tree is reserved for the system administrator's use. Such files on Debian systems go under /usr instead."
[23:18:16] <alex_joni> reading from :
http://www.debian.org/doc/manuals/maint-guide/ch-modify.en.html
[23:19:32] <paul_c> Same for most packaging systems.
[23:19:49] <alex_joni> so ${prefix} in emc2 should be /usr ?
[23:20:06] <alex_joni> or only when building packages?
[23:21:18] <paul_c> suggestion: Defaults to /usr/local and accepts other paths (for example, when building a package)
[23:22:26] <alex_joni> yup... now reading through the building of debs I see why $DESTDIR is needed
[23:22:35] <alex_joni> guess for rpms too...
[23:29:48] <paul_c> both rpm and deb need to be able to build in one dir, install in a second - Neither will be the final destination.
[23:33:18] <paul_c> BTW
[23:33:42] <paul_c> alex_joni: Do you have access to the ISO spec for G codes ?
[23:33:56] <alex_joni> nope, just what I downloaded from the net
[23:34:08] <alex_joni> from NIST I think (the RS274NGC documents)
[23:34:25] <alex_joni> don't think that's what you had in mind...
[23:35:12] <paul_c> the NIST docs are drawn from a number of sources - Some are suspect...
[23:35:40] <alex_joni> * alex_joni is experiencing weird problems...
[23:36:06] <alex_joni> with his current internet connection
[23:37:27] <alex_joni> does paul_c has some TCP/IP-knowledge?
[23:37:36] <alex_joni> s/has/have/
[23:40:59] <paul_c> limited
[23:41:50] <alex_joni> I have a problem that my computer (and others here) enter a SYN_SENT state, from which they don't come out (only after quite some time)
[23:42:42] <alex_joni> SYN_SENT is when there's no response to a SYN yet. I think the response got lost or smthg.. but the timeout is too big... and I don't know where to set it
[23:44:38] <paul_c> are you running through a trasparent proxy ?
[23:44:47] <alex_joni> NAT on a linux box
[23:45:31] <alex_joni> but it's happening on the linux box too... (I am running squid too, so some users access the net through squid)
[23:53:07] <paul_c> Can't help there I'm afraid.
[23:53:41] <alex_joni> I thought so... can't seem to find anyone to know ;)
[23:53:59] <alex_joni> anyways..
[23:54:03] <paul_c> try #debian
[23:54:03] <alex_joni> about autoconf emc2
[23:56:44] <paul_c> after lunch ?
[23:56:53] <alex_joni> sure...