Back
[12:03:51] <alex_jon3> alex_jon3 is now known as alex_joni
[15:33:29] <skunkworks> woo hoo.
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140036713477
[15:33:42] <skunkworks> that should complete my output stage
[15:34:06] <skunkworks> make it sort of hard for me to destroy :)
[15:35:15] <alex_joni> a bit pricy
[15:35:19] <alex_joni> I use those all the time ;)
[15:35:34] <alex_joni> actually the 8060
[15:35:46] <alex_joni> and the 10060
[15:35:49] <skunkworks> cool
[15:36:13] <skunkworks> It was cheaper than I could get from digikey/mouser. What source do you have?
[15:36:25] <alex_joni> someone in europe :)
[15:36:30] <alex_joni> germany somewhere
[15:36:39] <alex_joni> about 1EUR / piece
[15:36:46] <skunkworks> nice
[15:36:48] <alex_joni> maybe not lots cheaper then you got them
[15:37:03] <alex_joni> these are used on our welding inverters
[15:37:07] <skunkworks> what do you use them for?
[15:37:08] <skunkworks> ah
[15:37:18] <alex_joni> 250kHz or so
[15:37:56] <skunkworks> you guys design your own?
[15:38:19] <skunkworks> or is if to repair?
[15:40:35] <alex_joni> repair
[15:40:58] <alex_joni> design wouldn't be bad.. but production would be
[15:42:53] <skunkworks> makes sense
[15:43:03] <skunkworks> miller? :)
[15:43:09] <alex_joni> no.. cloos ;)
[15:43:14] <alex_joni> german manufacturer
[15:43:21] <alex_joni> probably less known in the US
[15:43:47] <skunkworks> yah- I have not heard of them - but that doesn't say much
[15:45:06] <skunkworks> are yours used strictly for rectifying?
[15:49:49] <alex_joni> yeah
[15:56:36] <skunkworks> they say they are Ultra-Fast ;)
[15:56:56] <alex_joni> few hundred kHz should be ultra-fast
[15:57:01] <alex_joni> plan to work them faster?
[16:04:29] <skunkworks> nope - probably what ever emc can put out :)
[16:04:47] <skunkworks> how ever fast the computer is that I use.
[16:05:00] <skunkworks> (going to be used for free-wheeling diodes)
[16:05:05] <alex_joni> so you plan to drive them directly from the parport ?
[16:05:38] <skunkworks> that is the plan - like what cradek and jepler did. - I think jmk was the first one to try it.
[16:06:27] <skunkworks> I think version 1 will not have current limit. (that is what fuses are for ;))
[16:06:41] <alex_joni> just remember to use FF ones
[16:06:53] <skunkworks> FF?
[16:06:56] <alex_joni> and bare in mind a fuse blows slower than a transistor
[16:06:59] <alex_joni> very fast
[16:07:06] <skunkworks> right
[16:07:26] <alex_joni> I know T, M, F, FF typed fuses
[16:07:33] <skunkworks> I know that from my amplifier building days. Thermal run away was faster than the fuse :)
[16:12:13] <skunkworks> My only plan in the back of my mind would be a small power resister (.1-.01 ohm or so) that is running into an op-amp set up as a comparater. This would disable the logic going into the 2 ir2111 - using like and "and"(or equivilent) gate.
[16:13:03] <skunkworks> if that made sense
[16:13:38] <alex_joni> yup
[16:13:48] <alex_joni> that's how current limiters usually work
[16:14:05] <alex_joni> except the other input of the op-amp comes from a variable resistor
[16:14:13] <skunkworks> I didn't know if there was a more elegent way. Have not really looked
[16:14:14] <skunkworks> right
[16:14:26] <skunkworks> that was the plan - adjustable current limti
[16:14:30] <skunkworks> limit
[16:14:39] <alex_joni> that's how I planned
[16:14:49] <alex_joni> for my DC drives .. back in college ;)
[16:14:57] <alex_joni> never got to implement it though :D
[16:15:10] <alex_joni> it worked without.. I could even stall the motor with my hand, and it was ok
[16:15:21] <skunkworks> (that is why I am thinking version 1 isn't going to have it :))
[16:15:40] <skunkworks> once I blow one up because of it - than I may add it :)
[16:15:58] <alex_joni> the first time I tried it I didn't blow the fuse
[16:16:06] <alex_joni> I actually blew the traces on the board :D
[16:16:17] <skunkworks> nice
[16:16:32] <alex_joni> then I soldered thick wires along the traces
[16:17:28] <skunkworks> I have to say - I don't think i have ever burned traces of a board yet
[16:17:50] <alex_joni> heh.. these were about 6mm wide
[16:17:57] <skunkworks> wow
[16:17:58] <alex_joni> but I think the copper wasn't very thick
[16:21:44] <skunkworks> bbl - going to drive my father to madison to pick up a new car.
[16:21:52] <alex_joni> later..
[16:22:20] <skunkworks> thanks for listening to me blabber
[16:24:01] <alex_joni> anytime :)
[17:55:55] <jepler> http://pastebin.ca/186972
[17:56:52] <jmkasunich> wow
[17:57:04] <alex_joni> what's rtapi_app ?
[17:57:22] <jepler> rtapi_app is something new
[17:57:38] <alex_joni> I figured that ;)
[17:57:42] <jepler> it is the unix process in which all the "real-time" components (ones with exported functions) are loaded
[17:58:05] <jmkasunich> is it using dlopen or such?
[17:58:08] <jepler> yes
[17:58:30] <jmkasunich> how much change to pid.c was needed to compile it as a shared lib?
[17:58:37] <cradek> ah so that's the secret to getting halscope to work too?
[17:58:44] <alex_joni> cool
[17:59:04] <jepler> jmkasunich: not much at all
[17:59:12] <jepler> anyway I don't have threads working yet
[17:59:16] <jepler> so it still can't do anything
[17:59:27] <jmkasunich> but its a big step in the right direction
[17:59:29] <alex_joni> jepler: it's a lot more than before ;)
[17:59:46] <jmkasunich> linux threads running as part of rtapi_app might be able to do that
[18:00:33] <jepler> the existing sim_rtapi seemed to have the beginning of an implementation with pthreads
[18:00:36] <jepler> I'm trying to finish that up
[18:28:23] <jepler> http://pastebin.ca/186997
[18:28:28] <jepler> if you don't look at it wrong, the thread runs...
[18:28:56] <jmkasunich> I won't look
[18:31:10] <jepler> ... I just ran halscope ...
[18:31:24] <cradek> woooo
[18:32:17] <jepler> if I load another component after I load 'threads', or maybe after I start it, I get a segmentation fault in thread_task which now has corrupt data instead of the list of functions in the thread
[18:33:42] <jmkasunich> can the sim stuff build and run with a RT kernel?
[18:34:57] <jepler> this is running on a -magma kernel but without any of the modules loaded
[18:35:05] <jepler> I haven't actually tested it on a vanilla kernel
[18:35:38] <jmkasunich> you haven't broken normal RT running have you?
[18:35:49] <jmkasunich> if not, commit and let me take a look
[18:36:22] <jepler> I don't know if I have
[18:36:24] <jepler> I'll put a patch up
[18:37:25] <alex_joni> wooo.. this is great
[18:38:11] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/nort.patch
[18:38:26] <jepler> in fact, reviewing what I did to the components, it's quite likely I broke "normal" systems
[18:38:51] <jepler> here's how you can get a thread with siggen and scope_rt running in it:
[18:39:40] <jepler> rtapi_app load siggen & # background the first instance of rtapi_app
[18:39:47] <jepler> rtapi_app load scope_rt
[18:39:52] <jepler> rtapi_app load threads
[18:40:11] <jmkasunich> you are running multiple instances of rtapi_app?
[18:40:18] <jepler> halcmd: addf siggen.0.update thread1
[18:40:18] <jepler> halcmd: addf scope.sample thread1
[18:40:18] <jepler> halcmd: start
[18:40:20] <jmkasunich> I don't think that will work
[18:40:46] <jepler> rtapi_app is all one process
[18:40:55] <jepler> subsequent instances just communicate their commandline over a FIFO
[18:41:18] <jmkasunich> oh, ok
[18:41:19] <jepler> that's why only the first instance has to be backgrounded, the rest exit right away
[18:41:53] <jmkasunich> strange, my cvs checkout attempt is stalled
[18:42:07] <jepler> now if you 'rtapi_app load pid' after doing all that, rtapi_app will crash in thread_task(). If you have a gdb attached you can inspect it at this point.
[18:42:10] <jmkasunich> this is right isn't it: cvs -z5 -d:ext:jmkasunich@cvs.sourceforge.net/cvs co -d nonrt emc2
[18:42:21] <jepler> looks right to me
[18:42:32] <jmkasunich> I get nothing... just waits and waits
[18:42:38] <alex_joni> wasn't it nort ?
[18:42:39] <jepler> sourceforge ??
[18:42:48] <jmkasunich> duh
[18:42:50] <jepler> @cvs.linuxcnc.org
[18:43:05] <alex_joni> jepler: did you check it in?
[18:43:07] <jmkasunich> much better
[18:43:24] <jmkasunich> alex_joni: no, I'm checking out a fresh copy of head to apply the patch to
[18:43:46] <alex_joni> oh,duh.. it's -d not -r
[18:44:39] <alex_joni> jepler: do you need string.h in tp.c ?
[18:45:46] <jepler> alex_joni: it was needed for a declaration of ... something
[18:46:11] <alex_joni> I don't see other changes to tp.c in that diff, that's why I asked
[18:46:17] <jmkasunich> comment it out and see what complains
[18:47:54] <jmkasunich> jepler: what was the invocation for configure again? --enable-sim or something like that?
[18:48:34] <jepler> ./configure --help should say it
[18:48:36] <alex_joni> ./configure --enable-simulator
[18:48:54] <alex_joni> or --eanble-simulator (but I bet that was a typo from jeff ;)
[18:48:57] <jmkasunich> and I assume I still want run-in-place
[18:49:06] <alex_joni> jmkasunich: right
[18:49:16] <alex_joni> and maybe not build docs too for now
[18:49:50] <jmkasunich> should I get "checking for rtai_ksched... find: ${exec_prefix}: No such file or directory
[18:49:50] <jmkasunich> not found
[18:49:50] <jmkasunich> " even tho I'm configuring for sim?
[18:50:23] <jepler> yeah it does that
[18:50:28] <jepler> ignore it for now
[18:50:57] <jmkasunich> building
[18:51:05] <jmkasunich> do I need make setuid?
[18:51:07] <jepler> n
[18:51:08] <jepler> o
[18:52:51] <jepler> is one of the items in the funct_root linked list supposed to have a bad pointer in it?
[18:53:17] <jmkasunich> gonna have to refresh my memory, just a sec
[18:53:34] <jepler> before crashing that entry is already there, but when it crashes that's the bad instruction pointer value
[18:55:23] <jepler> http://pastebin.ca/187032
[18:56:35] <jmkasunich> I'm still catching up
[18:56:58] <alex_joni> why is there the same entry twice in the list?
[18:57:17] <alex_joni> or is it circular?
[18:57:24] <jepler> it's a circular list
[18:57:56] <jmkasunich> I don't have rtapi_app
[18:57:58] <alex_joni> right
[18:58:16] <jmkasunich> checked out cvs head, applied the patch, configured with sim and rip enabled, and did make
[18:58:27] <jmkasunich> but no bin/rtapi_app
[18:59:42] <jepler> hmm
[18:59:51] <jepler> must have missed something in that patch I generated, then
[19:00:03] <jepler> what happens if you ask for it: make ../bin/rtapi_app
[19:00:40] <jmkasunich> john@ke-main-ubuntu:~/emcdev/nonrt/src$ make ../bin/rtapi_app
[19:00:40] <jmkasunich> make: *** No rule to make target `../bin/rtapi_app'. Stop.
[19:00:49] <jmkasunich> what file is the source in?
[19:00:58] <jepler> I put something in Makefile.inc by hand .. hm, what was it.
[19:01:00] <jmkasunich> I don't have a rtapi_app.c
[19:01:24] <jmkasunich> john@ke-main-ubuntu:~/emcdev/nonrt/src$ find . -name "rtapi*"
[19:01:24] <jmkasunich> ./rtapi
[19:01:24] <jmkasunich> ./rtapi/rtapi.h
[19:01:24] <jmkasunich> ./rtapi/rtapi_app.h
[19:01:24] <jmkasunich> ./rtapi/rtapi_common.h
[19:01:25] <jmkasunich> ./rtapi/rtapi_math.h
[19:01:29] <jmkasunich> ./rtapi/rtapi_math_i386.h
[19:01:31] <jmkasunich> ./rtapi/rtapi_proc.h
[19:01:33] <jmkasunich> ./depends/rtapi
[19:01:35] <jmkasunich> ./objects/rtapi
[19:02:16] <jepler> -BUILD_SYS =
[19:02:16] <jepler> +BUILD_SYS = sim
[19:02:40] <jmkasunich> in Makefile.inc?
[19:03:32] <jepler> yes
[19:04:16] <jmkasunich> much better
[19:04:35] <jepler> rtapi_app builds from sim_rtapi_app.c
[19:04:44] <jmkasunich> right, figured that out
[19:04:50] <jepler> ok
[19:04:56] <jmkasunich> .cc actually
[19:05:06] <jmkasunich> I think?
[19:05:53] <jepler> yes
[19:07:19] <jmkasunich> ok, I loaded siggen, scope_rt, addf'ed both functions
[19:07:34] <jmkasunich> then I did halcmd show thread, everything is fine
[19:07:36] <jepler> ok
[19:07:41] <jmkasunich> load pid
[19:07:52] <jmkasunich> halcmd show thread again, everything still fine
[19:07:54] <jepler> oh really
[19:07:59] <jmkasunich> (note - I haven't started the threads yet)
[19:08:10] <jepler> oh
[19:08:19] <jepler> what happens if you 'start'?
[19:08:38] <jmkasunich> still working
[19:08:48] <jmkasunich> (I added a pid funct to the thread first)
[19:08:52] <jepler> I wonder if the way functions are added to threads is unsafe
[19:08:53] <jmkasunich> now to load yet another comp...
[19:09:17] <jepler> but I'm not even doing a subsequent addf, just loading once it's started
[19:09:45] <jmkasunich> hmm
[19:10:21] <jmkasunich> I did the start, then a show, and everything looked fine
[19:10:31] <jmkasunich> then I tried another addf (pid.1)
[19:10:43] <jmkasunich> and it said no such funct (even tho the previous show showed it)
[19:10:54] <jmkasunich> then I did another show, and everything is gone (pins, params, etc)
[19:11:08] <jepler> probably your rtapi_app exited somewhere in there
[19:11:18] <jepler> if one thing crashes, the next halcmd may show the old stuff once
[19:11:45] <jmkasunich> duh, you are right
[19:12:08] <jmkasunich> start, shoe, segfault
[19:12:11] <jmkasunich> show
[19:13:10] <jmkasunich> strange that a show (which traverses the list) could corrupt it so that the subsequent run of the thread would read trash
[19:13:38] <jmkasunich> once rtapi_app exits, I have a clean slate, right?
[19:13:55] <jmkasunich> unlike the module version where I need to unload stuff before I try again
[19:14:19] <jepler> make sure it's empty with 'halcmd'
[19:14:50] <jepler> if the last component (or rtapi_app) exits uncleanly, the shared memory isn't cleaned up
[19:14:58] <jepler> but the subsequent run of halcmd does clean up when it exits
[19:15:03] <jmkasunich> ok
[19:15:35] <jmkasunich> I don't recall this from the first time:
[19:15:35] <jmkasunich> john@ke-main-ubuntu:~/emcdev/nonrt$ bin/rtapi_app load siggen &
[19:15:35] <jmkasunich> [1] 849
[19:15:35] <jmkasunich> john@ke-main-ubuntu:~/emcdev/nonrt$ Waited 3 seconds for master. giving up.
[19:15:35] <jmkasunich> master
[19:15:35] <jmkasunich> hal_init RTAPI
[19:15:37] <jmkasunich> SIGGEN: installed 1 signal generators
[19:16:35] <jepler> also an issue with error shutdown
[19:17:03] <jepler> if the fifo /tmp/rtapi_fifo exists already, this instance tries to be a slave but gives up and turns into the master after 3 seconds
[19:17:14] <jmkasunich> ok
[19:20:26] <jmkasunich> I just had a "failure to release mutex" from rtapi_all
[19:20:27] <jmkasunich> app
[19:20:58] <jmkasunich> I loaded siggen and threads, started the thread, addf'ed siggen.0.update to the thread, and all was wekk
[19:21:00] <jmkasunich> well
[19:21:13] <jmkasunich> tried to load pid, and that appeared to work
[19:21:17] <jmkasunich> but halcmd show hung
[19:21:22] <jmkasunich> halcmd -R freed it
[19:21:53] <jepler> It's because SHMPTR changed
[19:22:13] <jepler> or, rather, hal_shmem_base
[19:22:15] <jmkasunich> pid installes 3 blocks by default... but this time I only got 2
[19:22:42] <jepler> huh
[19:22:47] <jepler> was it while rtapi_app was busy dying?
[19:24:48] <jmkasunich> john@ke-main-ubuntu:~/emcdev/nonrt$ bin/rtapi_app load pid
[19:24:48] <jmkasunich> slave
[19:24:48] <jmkasunich> hal_init RTAPI
[19:25:42] <jmkasunich> I think a successfull load prints more, but its scrolled out of my buffer
[19:26:06] <jmkasunich> looks like rtapi_app died while doing the load pid
[19:26:24] <jmkasunich> but the segfault didn't appear on the screen until after halcmd show (and halcmd -R)
[19:26:51] <jepler> I think I figured out the segfault problem
[19:26:57] <jmkasunich> I feel like such an idiot - I used to know this code like the back of my hand, and now I'm stumbling around in the dark
[19:27:43] <jepler> on each hal_init() call, hal_shmem_base is being set to a new value, so the test while (funct_entry != funct_root) is wrong
[19:28:24] <jepler> now I've successfully done a 'rtapi_app load' after 'halcmd start'
[19:30:03] <jmkasunich> "each" hal_init() call?
[19:30:22] <jmkasunich> you mean the master rtapi_app process is calling hal_init more than once?
[19:30:32] <jepler> yes
[19:30:43] <jmkasunich> cain't do that
[19:31:26] <jmkasunich> all the funct pointers in the various lists are based on a particular mapping of the shmem block to user space addresses
[19:31:36] <jmkasunich> if you remap, they're all busted
[19:31:42] <jepler> it needs to be possible, though, or this won't work
[19:32:08] <jmkasunich> why can't the master do a hal_init when it starts and keep the shmem mapped constantly?
[19:32:38] <jepler> because everything calls hal_init() in its rtapi_app_main()
[19:33:19] <jmkasunich> so each component is doing a hal_init when you load it....
[19:33:35] <jepler> right
[19:33:44] <jmkasunich> eww
[19:34:06] <jmkasunich> that means after you load 10 components, you've had 10 mappings of shmem to process memory space
[19:35:17] <jepler> yeah
[19:35:17] <jmkasunich> how does the master instance run the threads if it doesn't keep its mapping open indefinitely?
[19:35:33] <jepler> I think I just need to fix sim_*lapi to map each thing only once
[19:35:48] <jepler> so if you hal_init 6 times you get one shared memory mapping which stays valid until you hal_exit all 6 components
[19:36:00] <jmkasunich> that sounds right
[19:39:13] <jmkasunich> you are treating hal_lib as "just another component" aren't you?
[19:40:09] <jepler> something like that
[20:01:24] <jepler> yep with this change it gets mapped only once...
[21:07:21] <jepler> hooray
[21:07:35] <jepler> it's good enough to run axis
[21:08:09] <jepler> with userspace HAL threads
[21:08:25] <jmkasunich> cool!
[21:10:40] <alex_joni> yay
[21:22:17] <jepler> bbl
[21:41:43] <cradek> this no-rt is really exciting
[21:41:56] <cradek> the last big piece we're missing from emc1
[21:44:47] <SWPadnos> I noticed the message
[21:44:51] <SWPadnos> way to go, Jepler
[21:46:24] <cradek> I wonder why he's sending around patches instead of using a branch
[21:46:29] <cradek> I keep missing him
[21:46:59] <SWPadnos> damfine question
[21:53:28] <jepler> cradek: because I'm a bit scared about using branches, and once I'm on a branch I can't just "cvs up" to get the latest changes from the trunk,
[21:53:58] <SWPadnos> unless you maintain two dirs on your machine ...
[21:54:20] <jepler> oh I've got a whole raft of directories
[21:54:50] <cradek> it's true about cvs up, I was assuming the branch wouldn't be in use for long, just to let us help you test etc.
[21:55:10] <cradek> as for being scared of branches, it's very easy
[21:56:39] <jepler> OK, tell me how and I'll do it
[21:56:51] <cradek> man cvs, search for "Creating the branch after editing"
[21:57:01] <cradek> that's how I always do it
[21:57:19] <cradek> [[ hacked sources are present ]]
[21:57:19] <cradek> $ cvs tag -b EXPR1
[21:57:19] <cradek> $ cvs update -r EXPR1
[21:57:19] <cradek> $ cvs commit
[21:57:37] <jepler> and what do I call the branch?
[21:57:51] <cradek> nort_testing
[21:58:19] <jepler> cvs update -cvs tag: nothing known about sim_common.h
[21:58:20] <jepler> cvs tag: nothing known about sim_rtapi_app.cc
[21:58:20] <jepler> rcvs [tag aborted]: correct the above errors first!
[21:58:33] <jepler> I created new files
[21:58:42] <cradek> ugh
[21:59:01] <SWPadnos> will cvs add fix that (without a commit in between)?
[21:59:13] <cradek> yes I bet it will
[21:59:25] <jepler> these are files I added already but didn't yet commit
[21:59:30] <SWPadnos> (asking because I dunno shit about CVS :) )
[21:59:53] <SWPadnos> I guess not then ;)
[22:00:14] <cradek> sorry I led you wrong
[22:02:15] <jepler> that's ok .. a rm / mv cycle seems to have fixed it
[22:02:16] <jepler> we'll see
[22:02:51] <cradek> I'm updating, I'll see if it builds
[22:03:03] <jepler> I am pretty sure realtime won't build
[22:03:11] <cradek> U src/rtapi/sim_rtapi_app.cc
[22:03:42] <cradek> and then with up -A:
[22:03:43] <cradek> cvs update: src/rtapi/sim_rtapi_app.cc is no longer in the repository
[22:03:47] <cradek> so you did it right
[22:03:57] <jepler> oh good
[22:04:01] <jepler> * jepler leaves again
[22:04:15] <cradek> ok bye
[22:06:45] <SWPadnos> seeya japler
[22:23:51] <SWPadnos> urk - bedtime
[22:24:02] <SWPadnos> see you guys later (like tomorrow maybe)
[22:24:17] <alex_joni> it already is tomorrow :)
[22:24:22] <SWPadnos> so it is
[22:24:34] <SWPadnos> that must be why I'm getting tired
[22:24:58] <alex_joni> SWPadnos: you in germany yet?
[22:25:02] <SWPadnos> I'm in Düsseldorf
[22:25:06] <alex_joni> coo
[22:25:15] <alex_joni> get an 'Alt'
[22:25:22] <SWPadnos> what if I hate beer?
[22:25:29] <alex_joni> then not :)
[22:25:31] <SWPadnos> heh
[22:25:49] <SWPadnos> I've had sauerbraten and various kinds of herring though
[22:25:58] <alex_joni> eisbein?
[22:26:06] <SWPadnos> ?
[22:26:18] <alex_joni> some nice thing to order the next time ;)
[22:26:51] <SWPadnos> ah - schweinehaxen
[22:26:56] <alex_joni> yup
[22:27:04] <SWPadnos> had some already :)
[22:27:26] <alex_joni> eisbein mit sauerkraut
[22:27:45] <SWPadnos> I actually had Thai food tonight - I can't think of any more German "favorites" ;)
[22:28:10] <SWPadnos> ja - grosse sauerkrautplaten
[22:28:14] <alex_joni> SWPadnos: I was at a geat north koreean restaurant in düsseldorf
[22:28:26] <SWPadnos> really - do you remember the name?
[22:28:26] <alex_joni> that was the best thing I had while there ;)
[22:28:32] <alex_joni> not by heart
[22:28:40] <alex_joni> but I don't suspect there are that many
[22:28:45] <SWPadnos> I love korean food (not sure if it's north or south)
[22:30:25] <SWPadnos> hmmm - is it in Old Town?
[22:31:01] <SWPadnos> Shilla?
[22:31:05] <alex_joni> might have been Ga-ya
[22:31:31] <alex_joni> http://www.wz-newsline.de/sro.php?redid=90050
[22:31:46] <SWPadnos> hmmm - I only see two in this cuty guide:
http://travel.yahoo.com/p-travelguide-7004915-cit-dusseldorf-countryname-germany-cus-korean-europe_restaurants-i;_ylt=AojNBzYxE8BsPp22dcKA_wjoDmoLEurope Restaurants: Read Reviews of Restaurants in Europe - Yahoo! Travel
[22:31:52] <SWPadnos> argh
[22:34:00] <SWPadnos> what's funny is that water is often more expensive than beer
[22:35:06] <alex_joni> I found 5 pictures from inside the restaurant
[22:35:12] <alex_joni> from over 1 year ago
[22:35:18] <alex_joni> but I can't make out any names :)
[22:36:13] <alex_joni> the chopsticks say "Kim's Asia", but it's probably not the restaurant name :)
[22:38:42] <SWPadnos> heh - probably not ;)
[22:39:00] <alex_joni> that's a asia supermarket in düsseldorf ;)
[22:39:18] <SWPadnos> or in Seoul :)
[22:39:31] <alex_joni> no, in düsseldorf .. google found it :)
[22:39:38] <SWPadnos> ah
[22:43:12] <alex_joni> http://www.stadtplandienst.de/map.asp?sid=982ace02dc4bd8b4e76f172bf69e4e93&ix=154&iy=948&grid=dedatlas10
[22:43:16] <alex_joni> somewhere in that area
[22:43:20] <alex_joni> but my memory is dim