|
USB
Jan 25, 2008 19:05:59 GMT -5
Post by zoomkat on Jan 25, 2008 19:05:59 GMT -5
Oooo..., that is a workaround. Looks like RB will be limited to only manipulating files.
|
|
|
USB
Jan 25, 2008 22:40:01 GMT -5
Post by carlgundel on Jan 25, 2008 22:40:01 GMT -5
Oooo..., that is a workaround. Looks like RB will be limited to only manipulating files. For now, yes, but we'll get there. -Carl
|
|
|
USB
Jan 28, 2008 16:13:21 GMT -5
Post by neiljeff on Jan 28, 2008 16:13:21 GMT -5
It seems to me that a workaround to access local I/O quick enough for the moment would be: RB [reading/writing to] RAMdisk [reading/writing to] LB [reading/writing to] serial/USB/IOport.
The LB segment could be fairly small, effectively creating a "RAMdrive_DLL" written in LB (or ANother), to access I/O ports. The RAMdrive speed improvements are likely to be a few orders quicker than HDDrive file access, but does anyone know what the switching delays are likely to be between RB and LB with this arrangement?
|
|
|
USB
Jan 28, 2008 16:24:50 GMT -5
Post by BillSturm on Jan 28, 2008 16:24:50 GMT -5
I am interested in hardware access also.
Instead of a ramdisk and files, I was thinking of trying SQLite to read devices in LB and send the data to RB. Maybe I'll still need a ramdisk if SQLite commit flushes to disk. SQLite "may" have the benefit of record locking to eliminate concurrency issues, I haven't actually tried it yet though. Does this sound like a feasible idea?
Named pipes are another possibility, if LB can create them and RB can open them like files. Maybe?
|
|
|
USB
Jan 28, 2008 16:42:25 GMT -5
Post by mikeukmid on Jan 28, 2008 16:42:25 GMT -5
Using a ramdisk file, RB and LB both read and write to the same file so some error trapping/retry is needed which can introduce a delay. The required action is of course not instantaneous and the network transmission time plays a large part in the effectiveness. Sometimes the message from the browser can take a while to reach the server and vice-versa. All depends on how time critical your application is. If the read/write interval is too short, I find that the LB part of it gets stuck in the error trap loop as though both RB and LB are always trying to access the file at the same time and neither succeed.
If response time is critical then probably remote control via the internet is not suitable.
My application only accesses the ramdisk every 2 seconds and seem to work trouble free.
HTH
Mike.
|
|
|
USB
Jan 28, 2008 16:46:57 GMT -5
Post by carlgundel on Jan 28, 2008 16:46:57 GMT -5
Using a ramdisk file, RB and LB both read and write to the same file so some error trapping/retry is needed which can introduce a delay. You can try writing a staging file, closing it, and then renaming it. If the reader of the file sees the file then it is not open and is free to be read. The reader deletes the file once it is read. The writer of the file can see whether the file still exists. Could work. -Carl
|
|
|
USB
Jan 28, 2008 17:14:32 GMT -5
Post by neiljeff on Jan 28, 2008 17:14:32 GMT -5
Carl, that's nice and clean...
|
|
|
USB
Jan 28, 2008 19:55:09 GMT -5
Post by BillSturm on Jan 28, 2008 19:55:09 GMT -5
That IS a nice simple protocol for file access, I like it also.
Now, how do we get a ramdisk in Windows, I've only made these in MS-DOS. Is there a Win32 API call?
|
|
|
USB
Jan 28, 2008 20:03:40 GMT -5
Post by StefanPendl on Jan 28, 2008 20:03:40 GMT -5
Now, how do we get a ramdisk in Windows, I've only made these in MS-DOS. Is there a Win32 API call? There is no API, you will need a bunch of them to create a virtual disk. There are freeware RAMdisks around, just Google
|
|
|
USB
Jan 28, 2008 22:17:08 GMT -5
Post by plankyprograms on Jan 28, 2008 22:17:08 GMT -5
I am looking to do a similar method of using files to 'talk' to one of my LB programs. I just wonder about a few aspects and would appreciate any thoughts. 1) Contention: What if you expose your RB application to the internet and have 300 users 'logged on' -, and they all decide to trigger a USB output (ie move a USB camera) at the same time - thus several clients would be asking RB to create the same local disk-file? 2) What if your LB program hangs for some reason. Perhaps my question (1) is because I don't yet know/understand how the server operates in servicing multiple client events - ie does RB exclusively service 'client 1' until it comes across a 'wait' statement - then runs for the next 'client 2' event (again having full control until a 'wait' statement)? - or is each client's place in the program 'time-switched'? My solution to (2) would be that Carl's method could be slightly enhanced to give some 'handshaking' such that the RB program is as follows: RB Server Prog - Add timeout waiting for last instruction to be processed1) Check if 'DoUSB.txt' exists on local-disk
2) If 'yes' then loop for maximum of 2-seconds - then if still not deleted report back to client an error (and 'wait')
3) Write new instruction to 'NextUSB.txt', then rename file to 'DoUSB.txt'
4) Wait (for next event)LB Prog - Same as Carl's, but deletes the file after processing1) Wait for 'DoUSB.txt' to exist.
2) If found, read content and output/input to USB
3) Delete (kill) 'DoUSB.txt'I hope this post makes sense. I've only just installed RB and still trying to get into the correct frame of mind before I write my applications (two are urgent commercial applications) - but I'm very excited about the possibilities Note: In my case I'm not doing I/O but asking my LB program to supply an image on demand. It is a large (7000-line & bug-free) program analysing a large database and creating graphics - and I don't want to rewrite the LBv4 turtle-graphics commands to RB/LB5 format.
|
|
|
USB
Jan 28, 2008 22:31:53 GMT -5
Post by mackrackit on Jan 28, 2008 22:31:53 GMT -5
|
|
|
USB
Jan 28, 2008 22:33:46 GMT -5
Post by carlgundel on Jan 28, 2008 22:33:46 GMT -5
My solution to (2) would be that Carl's method could be slightly enhanced to give some 'handshaking' such that the RB program is as follows: Great except RB v1.0 doesn't have a NAME statement to rename files. Oops. If you give me a couple of days I can get you a prerelease version with that added in. -Carl
|
|
|
USB
Jan 28, 2008 22:43:11 GMT -5
Post by plankyprograms on Jan 28, 2008 22:43:11 GMT -5
Cheers Carl - I'm still going through this forum to get upto speed. What about my query regarding how each client is serviced if you had 300 logged-on?
Cheers Mackrackit - Thanks very much for your site - I had fun with it the other day and was going to use your code as a template.
|
|
|
USB
Jan 28, 2008 23:00:04 GMT -5
Post by carlgundel on Jan 28, 2008 23:00:04 GMT -5
Cheers Carl - I'm still going through this forum to get upto speed. What about my query regarding how each client is serviced if you had 300 logged-on? Cheers Mackrackit - Thanks very much for your site - I had fun with it the other day and was going to use your code as a template. That's a lot of users and would require a lot of memory. That would probably be your biggest issue in that scenario. However, if you're wondering how the time gets sliced up between running processes, it isn't just when you hit WAIT. Run BASIC also context switches while in loops, so running processes do not stop each other from doing work. I don't have the resources to test your particular use case. Run BASIC should be able to handle most applications with a dozen or so people at once, but this depends on many variables. Most applications spend most of their time sitting idle waiting for the user to do something. -Carl
|
|
|
USB
Jan 28, 2008 23:45:49 GMT -5
Post by plankyprograms on Jan 28, 2008 23:45:49 GMT -5
So taking our USB "file-handshaking" communication example (and multiple clients logged-on).....
It could be possible for "client 1" to have performed an "open NextUSB.txt for output" (assume here successfully, though not yet written/closed it) and then control taken away to another "client 2" process, which may also then try to do an identical "open NextUSB.txt for output". I guess that in that situation, for 'client 2', an ON ERROR event would be generated (as per Mackrackit's reply) as you can't have two instances of writing the same file by two (or more) clients at the same time.
In fact, now I think about it properly; shouldn't we (for orderly execution) always have an ON ERROR process whenever any local file is being opened by an RB application - just in the case of multiple-clients trying to write at the same time to the same file?
And if you agree: I guess the ON ERROR code could simply go back and try again for a specified number of loops or time-count until the conflict gets resolved.
Do you have a list somewhere of the Err variable error-code numbers - I've just checked Wiki but it doesn't seem to be specified.
|
|