Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
Zelimir Ikovic wrote: I have VB6 program that run CNC plasma machine. It work very well and smooth under win200, but in WinXP machine motion is not good. It doesnot help if I set REALTIME prority for the process ... How about Linux and Gambas? Daes it depent on version of Linux ... What is resolution for Gambas Timer? Can I wait 10 microsec do something wait 10 microsec and so on ... Regards Hi, First of all, I apologise for giving winxp help in a Gambas mailing list, I will make it brief. Parallel port access change when winxp came along. It was not so easy to get direct access to the port, and some versions of winxp look for devices by periodically writing to the port. This is may be the cause of poor motion. This can be fixed by setting the 'DisableWarmPoll' key in the registry. || -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] form_resize issue
Hello List, When the user resizes the main form of my application I try to follow the form size with the controls on the form. I use the Form_resize event and I modify the controls' position accordingly. My hierarchy is something like that: Form TabStrip1 TabStrip11 TableView111 TabStrib12 TableView121 TableView122 It seems working correctly for any control I'm looking at... but not always for the others. For instance if I'm on the TabStrip11 and I resize the form then the TableView111 behaves normally but if I go to check the TableView122 then I can see the previous size. I call the refresh method for each item after modifying it's position or size. Do I miss something or is it a bug? I use Ubuntu 9.10 (64 bit), Gambas 2.20. Robi Your explanation are not clear. Can you provide a little project that shows the problem? -- Benoît Minisini -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] form_resize issue
For the moment I just have a big one. I try to build a small example which shows the problem. Robi 2010/4/18 Benoît Minisini gam...@users.sourceforge.net Hello List, When the user resizes the main form of my application I try to follow the form size with the controls on the form. I use the Form_resize event and I modify the controls' position accordingly. My hierarchy is something like that: Form TabStrip1 TabStrip11 TableView111 TabStrib12 TableView121 TableView122 It seems working correctly for any control I'm looking at... but not always for the others. For instance if I'm on the TabStrip11 and I resize the form then the TableView111 behaves normally but if I go to check the TableView122 then I can see the previous size. I call the refresh method for each item after modifying it's position or size. Do I miss something or is it a bug? I use Ubuntu 9.10 (64 bit), Gambas 2.20. Robi Your explanation are not clear. Can you provide a little project that shows the problem? -- Benoît Minisini -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Hi Ed, After many tries, I managed to recreate your problem. It happens with your code and the code supplied by Dimitris. I am using Ubuntu 9.04, Kernel 2.6.28-18, Gambas 2.20.2, QT I have not managed to figure out the cause yet. I will do more tests and get back to you. Regards Les Hardy Ed Clare Kelm wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. The following code gets around the problem. It's not ideal, but it does work. Maybe someone else can improve on it. Regards Les Hardy PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String DIM t, txt AS String Label1.text = Fname = /home/les/Documents/testdat.txt tfile = OPEN Fname FOR READ IF NOT Eof(tfile) THEN LINE INPUT #tfile, t txt = IIf(Trim(t) , t, EOF) Label1.text = txt ELSE Label1.text = EOF ENDIF CLOSE #tfile END Ed Clare Kelm wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] form_resize issue
Hi Benoit, I put together the small project with 2 level of TabStrip controls and with tableview controls on some of them. First it seemed to work perfectly... but finally I could reproduce the effect on my computer. When the app starts up then (normally) the controls resize correctly. Just after keep your eyes on one of the tableviews and resize the form (I just change from maximized to normal window and back). The tableview I look at behaves normally. But when I check the others they have the size corresponds to the normal window size. Will be interesting to see if the same happens for you or if you find a silly mistake in the code. For the moment I didn't put any refreshing - I did it in the project I work on but didn't help. Regards, Robi 2010/4/18 Benoît Minisini gam...@users.sourceforge.net Hello List, When the user resizes the main form of my application I try to follow the form size with the controls on the form. I use the Form_resize event and I modify the controls' position accordingly. My hierarchy is something like that: Form TabStrip1 TabStrip11 TableView111 TabStrib12 TableView121 TableView122 It seems working correctly for any control I'm looking at... but not always for the others. For instance if I'm on the TabStrip11 and I resize the form then the TableView111 behaves normally but if I go to check the TableView122 then I can see the previous size. I call the refresh method for each item after modifying it's position or size. Do I miss something or is it a bug? I use Ubuntu 9.10 (64 bit), Gambas 2.20. Robi Your explanation are not clear. Can you provide a little project that shows the problem? -- Benoît Minisini -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user resize-0.0.1.tar.gz Description: GNU Zip compressed data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] form_resize issue
OK, I play a little tonight! But there is a risk that I ask questions tomorrow :D Thx a lot, Robi 2010/4/18 Fabien Bodard gambas...@gmail.com just do that to try : make a form and add 3 panel in it then in each panel add 3 other panels give an unique color for each panels and then try each properties and run the form ... it's the better way to understand 2010/4/18 Robert JUHASZ robert1juh...@gmail.com: For the moment I just have a big one. I try to build a small example which shows the problem. Robi 2010/4/18 Benoît Minisini gam...@users.sourceforge.net Hello List, When the user resizes the main form of my application I try to follow the form size with the controls on the form. I use the Form_resize event and I modify the controls' position accordingly. My hierarchy is something like that: Form TabStrip1 TabStrip11 TableView111 TabStrib12 TableView121 TableView122 It seems working correctly for any control I'm looking at... but not always for the others. For instance if I'm on the TabStrip11 and I resize the form then the TableView111 behaves normally but if I go to check the TableView122 then I can see the previous size. I call the refresh method for each item after modifying it's position or size. Do I miss something or is it a bug? I use Ubuntu 9.10 (64 bit), Gambas 2.20. Robi Your explanation are not clear. Can you provide a little project that shows the problem? -- Benoît Minisini -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Les Hardy ha scritto: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. Just breaking in to say that a file with a EOL in it is not an empty file - it is a file with an empty line in it... Given such a file, at first EOF is false; doing a LINE INPUT an empty line is read, then EOF turns true. Or, at least, it should go this way. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Dimitris Les: First Dimitris: OK, I pasted in your code. I had to change temp to tmp, because Temp seems to be a Keyword. With that out of the way, the problem persists. When it fails, I get EOF both in label1 and the debug window. When it works OK, I get a blank label1 and the text appears in the debug window. The state of being at EOF seems to arise (randomly) as soon as the file is opened. After that, everthing happens as one would expect - an EOF directs execution to the EOF stuff, and lack of EOF executes the text reading stuff. I can't believe this is a common problem - by now hundreds of people would have noticed that their database and any other programs reading a text file don't work reliably. There's got to be something peculiar about my installation. Now to Les: It still fails for me with your code. To clarify a little, the problem is that the file is detected as empty when it's not, not the other way around. Your code works like mine - when the file is opened it may randomly immediately come up as being at EOF. The IF not EOF... statement then sends it directly to the ELSE, and the game is over. If you can reproduce my problem by reading the same file over and over, closing the program after every try, but using Gambas 2.20.2, then I've got to suspect Ubuntu, at least the 9.04 I have. If you cannot, then I should upgrade Gambas. I suppose a shotgun approach might be to upgrade to Ubuntu 9.10 AND Gambas 2.20.2. Lastly, I don't think having a file with just a single 0A should be called empty. To me EOF means just that, End of File - no more data to be read. I would consider the 0A to be data, a blank line if you like. So, I think Gambas not raising EOF on such a file until the line is read is appropriate. Both: I'll chew on this for a few days, and then think about upgrading something. Thanks for your efforts! Ed K. Les Hardy wrote: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. The following code gets around the problem. It's not ideal, but it does work. Maybe someone else can improve on it. Regards Les Hardy PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String DIM t, txt AS String Label1.text = Fname = /home/les/Documents/testdat.txt tfile = OPEN Fname FOR READ IF NOT Eof(tfile) THEN LINE INPUT #tfile, t txt = IIf(Trim(t) , t, EOF) Label1.text = txt ELSE Label1.text = EOF ENDIF CLOSE #tfile END Ed Clare Kelm wrote: Hi! I'm having a problem reliably reading a text file. I am using: Panasonic CF-51 Toughbook Ubuntu 9.04 , Kernel 2.6.28-18 Gambas 2.8, QT Below is the code for a test program which demonstrates the problem. This is a simple form, with one button, and one label. The only code is the Button1_click event shown. The file testdat.txt contained in Fname is a text file with one short line of text, created with GEDIT. One would expect that clicking Button1 would open the file, read the line of text, and place it into label1. Indeed, this is exactly what happens roughly 4 times out of 5. However, sometimes the file comes up empty, with an immediate EOF. When the program is first started from the IDE, if it works correctly the first time, it will do so every time the button is clicked. However, if it fails (indicates EOF) the first time, it will fail everytime the button is clicked. Stopping the program and restarting it will roll the dice anew. There does not seem to be any pattern to the failure. It might happen twice in a row, it might not happen for 10 starts. Does anybody have any ideas? Is this an Ubuntu issue? Thanks! Ed K. PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
To run a stepper we need 2 pins: one for direction: 0 is clckwise, 5V is CounterClockWise. Second pin is for stepping. I have to bring 5V and keep it for 200 nanosec or more with WAIT1 SUB then bring 0V, and then I need precise amount of time to wait. It has to be precise because speed of machine depends on it I have to wait let say between 100 and 1 microsec. If I wait 100microsec machine will move at 10 inch per sec which is maximum I need Here is how I do it in VB6 on win2000 (On winXP it is not smooth I feel machine will fall apart, and there is not help for this I try everything, only solution is WinXPembedded): == Public Sub WAIT1(w As Long) Dim kf As Long For kf = 1 To w Next kf End Sub == Public Sub WAIT2(s As Double) Dim c1 As Currency Dim c2 As Currency QueryPerformanceCounter c1 Do QueryPerformanceCounter c2 Loop Until ((c2 - c1 - overhead) / freq) s End Sub == 'run this at begining of the program to measure freq Public Sub OVER() Dim CT1 As Currency Dim CT2 As Currency QueryPerformanceFrequency freq QueryPerformanceCounter CT1 QueryPerformanceCounter CT2 overhead = (CT2 - CT1) / freq End Sub Public freq As Currency Public overhead As Currency == --- On Sun, 4/18/10, Doriano Blengino doriano.bleng...@fastwebnet.it wrote: From: Doriano Blengino doriano.bleng...@fastwebnet.it Subject: Re: [Gambas-user] Did anybody try to run stepper motors through paralel port To: mailing list for gambas users gambas-user@lists.sourceforge.net Received: Sunday, April 18, 2010, 11:27 AM Les Hardy ha scritto: Zelimir Ikovic wrote: I have VB6 program that run CNC plasma machine. It work very well and smooth under win200, but in WinXP machine motion is not good. It doesnot help if I set REALTIME prority for the process ... How about Linux and Gambas? Daes it depent on version of Linux ... What is resolution for Gambas Timer? Can I wait 10 microsec do something wait 10 microsec and so on ... Regards Uhm... under linux, no matter what version, you can use the parallel port and high resolution timers, but... 10 us? What is the speed of your motor(s)? Anyway, I see it difficult to do it in gambas, mainly because of tight GUI integration and impossibility to use interrupts; the best way would be to separate hi-level logic from lo-level timing, perhaps through a library written in C. -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
Doriano Blengino wrote: Les Hardy ha scritto: Zelimir Ikovic wrote: I have VB6 program that run CNC plasma machine. It work very well and smooth under win200, but in WinXP machine motion is not good. It doesnot help if I set REALTIME prority for the process ... How about Linux and Gambas? Daes it depent on version of Linux ... What is resolution for Gambas Timer? Can I wait 10 microsec do something wait 10 microsec and so on ... Regards Uhm... under linux, no matter what version, you can use the parallel port and high resolution timers, but... 10 us? What is the speed of your motor(s)? Anyway, I see it difficult to do it in gambas, mainly because of tight GUI integration and impossibility to use interrupts; the best way would be to separate hi-level logic from lo-level timing, perhaps through a library written in C. Yes, I agree. I did a lot of work with parallel ports in the past, but I would not attempt a serious application for that job in Gambas. Since I retired, I have been building my own hobby CNC machines, but I just use EMC2. It is GPL, and very efficient, so I figured I had no need to write my own app. Les Hardy -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Doriano Blengino wrote: Les Hardy ha scritto: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. Just breaking in to say that a file with a EOL in it is not an empty file - it is a file with an empty line in it... Given such a file, at first EOF is false; doing a LINE INPUT an empty line is read, then EOF turns true. Or, at least, it should go this way. Regards, Your correct, I agree completely, but the original code Ed supplied, ' IF Eof(tfile) ' cannot work , as it checks eof before a read. When I saw he was using eof() that way, and knowing empty files are not always empty, I thought I had found his problem, so I just added a bit of code that should have got around it. I am sure you will agree, that, whatever other problems he may have, he needs not to use eof() the way he is. Regards Les Hardy -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
I wanted to know how predictable and reliable GAMBAS is when a reaction to real-world events is required. Let say that Java RealTimeSystem is intended only for suitable operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM. So that means it depends on underlynig OS version ... Simply installing an RTS extension and renaming java.lang.Thread instances to javax.realtime.RealtimeThread will not turn the application into a real-time app. I just wanted to know what is Gamas reaction to real world compared under different underlyng OS. FreeBSD, OpenBSD and Linux are not he same. --- On Sun, 4/18/10, Les Hardy l...@webmayo.com wrote: From: Les Hardy l...@webmayo.com Subject: Re: [Gambas-user] Did anybody try to run stepper motors through paralel port To: mailing list for gambas users gambas-user@lists.sourceforge.net Received: Sunday, April 18, 2010, 12:27 PM Doriano Blengino wrote: Les Hardy ha scritto: Zelimir Ikovic wrote: I have VB6 program that run CNC plasma machine. It work very well and smooth under win200, but in WinXP machine motion is not good. It doesnot help if I set REALTIME prority for the process ... How about Linux and Gambas? Daes it depent on version of Linux ... What is resolution for Gambas Timer? Can I wait 10 microsec do something wait 10 microsec and so on ... Regards Uhm... under linux, no matter what version, you can use the parallel port and high resolution timers, but... 10 us? What is the speed of your motor(s)? Anyway, I see it difficult to do it in gambas, mainly because of tight GUI integration and impossibility to use interrupts; the best way would be to separate hi-level logic from lo-level timing, perhaps through a library written in C. Yes, I agree. I did a lot of work with parallel ports in the past, but I would not attempt a serious application for that job in Gambas. Since I retired, I have been building my own hobby CNC machines, but I just use EMC2. It is GPL, and very efficient, so I figured I had no need to write my own app. Les Hardy -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Les Hardy ha scritto: Doriano Blengino wrote: Les Hardy ha scritto: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. Just breaking in to say that a file with a EOL in it is not an empty file - it is a file with an empty line in it... Your correct, I agree completely, but the original code Ed supplied, ' IF Eof(tfile) ' cannot work , as it checks eof before a read. When I saw he was using eof() that way, and knowing empty files are not always empty, I thought I had found his problem, so I just added a bit of code that should have got around it. I am sure you will agree, that, whatever other problems he may have, he needs not to use eof() the way he is. Here is the original code. I think it is perfectly right: PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END If eof() is not checked *before* reading, then when? I see only two things I would not do (but it depends a lot). First, why use the fname variable, if it is used only once... second, why set label1.text if that .text will be anyway written shortly later? But, apart from these two very little things, that can also have some good reason, the rest of the code is the only possible, I think. Note also that label1.text can get 3 different values: EOF is the file is empty; if the first line of the file is empty; something else if the first line of the file contains some data. These three cases cover all the cases we talked about (empty and not empty files), and I think our friends know what they are doing. Of course I may be wrong, but that use of eof() seems to me fully ok. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
On 19/04/10 04:17, Zelimir Ikovic wrote: I wanted to know how predictable and reliable GAMBAS is when a reaction to real-world events is required. Let say that Java RealTimeSystem is intended only for suitable operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM. So that means it depends on underlynig OS version ... Simply installing an RTS extension and renaming java.lang.Thread instances to javax.realtime.RealtimeThread will not turn the application into a real-time app. I just wanted to know what is Gamas reaction to real world compared under different underlyng OS. FreeBSD, OpenBSD and Linux are not he same. --- On Sun, 4/18/10, Les Hardy l...@webmayo.com wrote: From: Les Hardy l...@webmayo.com Subject: Re: [Gambas-user] Did anybody try to run stepper motors through paralel port To: mailing list for gambas users gambas-user@lists.sourceforge.net Received: Sunday, April 18, 2010, 12:27 PM Doriano Blengino wrote: Les Hardy ha scritto: Zelimir Ikovic wrote: I have VB6 program that run CNC plasma machine. It work very well and smooth under win200, but in WinXP machine motion is not good. It doesnot help if I set REALTIME prority for the process ... How about Linux and Gambas? Daes it depent on version of Linux ... What is resolution for Gambas Timer? Can I wait 10 microsec do something wait 10 microsec and so on ... Regards Uhm... under linux, no matter what version, you can use the parallel port and high resolution timers, but... 10 us? What is the speed of your motor(s)? Anyway, I see it difficult to do it in gambas, mainly because of tight GUI integration and impossibility to use interrupts; the best way would be to separate hi-level logic from lo-level timing, perhaps through a library written in C. Yes, I agree. I did a lot of work with parallel ports in the past, but I would not attempt a serious application for that job in Gambas. Since I retired, I have been building my own hobby CNC machines, but I just use EMC2. It is GPL, and very efficient, so I figured I had no need to write my own app. Les Hardy I have used Gambas for on-screen scrolling of large screens with a 3ms tick rate and it was pleasing to the eye (meaning no discernible jitter). The minimum time resolution - as I understand it - is 1 ms at present. You can of course calibrate your own timing loops if your application is the only job the computer has to do. Regards Werner Dahn -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
Zelimir Ikovic ha scritto: I wanted to know how predictable and reliable GAMBAS is when a reaction to real-world events is required. Let say that Java RealTimeSystem is intended only for suitable operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM. So that means it depends on underlynig OS version ... Simply installing an RTS extension and renaming java.lang.Thread instances to javax.realtime.RealtimeThread will not turn the application into a real-time app. I just wanted to know what is Gamas reaction to real world compared under different underlyng OS. FreeBSD, OpenBSD and Linux are not he same. I understand but, let me say, your sample code had nothing to do with realtime... it was simply fast as much as possible, without any mechanism to ensure some kind of real-time response to some event. To only read a counter is not enough. I can run 4 stepper motors directly (no step+direction, but driving the phases directly instead) with a CPU more than 100 times slower than a x86 CPU. But this is possible using interrupts. Practically every OS can, in some way, use interrupts - gambas can not. So, the only way in gambas to do precise timing is to let it run alone, with maximum priority and privileges. Or, to delegate high timing precision to some external piece of software (a libray or a driver) which can take advantage of interrupts, or callbacks, or signals. On the other hand I think that gambas can, with tight loops, do delays like you did in the original source. Surely it is predictable enough to let you calculate in some way the correct amount of cycling to obtain the needed delay - the fact is that gambas will never be the only thing running on the system, and you have little control about that. The same problem of windows xp - if you want precise timing, you must obtain privileges, either for the program or using a driver. I must also add that, without particular precautions, linux is more predictable about sleep() than win2000 or xp. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Hi all: A couple of comments about the discussions below: 1. The test program was written with EOF at the start, because the actual program I am working on has this structure, for reading in multiple lines of text: WHILE NOT EOF(tfile) (bunch of code for reading the lines in and putting the data in the proper places) WEND CLOSE #tfile When that failed, I wrote the test program to see if I was actually sometimes getting an EOF immediately after opening the file, since the first thing WHILE does is test EOF. 2. Clearing label1 after every button click is just a little insurance. Given that things weren't working as expected, I wanted to make sure what I saw in label1 was new info, not something left from the previous button click. I know that shouldn't be necessary, because the IF-THEN-ELSE structure will always write to the label - but then there shouldn't be an immediate EOF either. 3. Using Fname like that is just a little habit I've developed. It allows me to try a different file by commenting out one setting of Fname and writing a new one, without erasing the previous one. And it makes the OPEN statement more compact and easy to read. It is also sometimes useful to put such equates all in one place, so it's easy to find and change parameters, rather than rummaging around in the code. You are correct, it is sort of a waste if I am only using the variable once. In my actual program, Fname also gets used when the database gets modified and the file then has to be re-written. I am not a professional programmer, so I'm sure I have some ways of doing things that make professionals cringe! Thanks again for thinking about my problem! Regards, Ed K. Doriano Blengino wrote: Les Hardy ha scritto: Doriano Blengino wrote: Les Hardy ha scritto: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. Just breaking in to say that a file with a EOL in it is not an empty file - it is a file with an empty line in it... Your correct, I agree completely, but the original code Ed supplied, ' IF Eof(tfile) ' cannot work , as it checks eof before a read. When I saw he was using eof() that way, and knowing empty files are not always empty, I thought I had found his problem, so I just added a bit of code that should have got around it. I am sure you will agree, that, whatever other problems he may have, he needs not to use eof() the way he is. Here is the original code. I think it is perfectly right: PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END If eof() is not checked *before* reading, then when? I see only two things I would not do (but it depends a lot). First, why use the fname variable, if it is used only once... second, why set label1.text if that .text will be anyway written shortly later? But, apart from these two very little things, that can also have some good reason, the rest of the code is the only possible, I think. Note also that label1.text can get 3 different values: EOF is the file is empty; if the first line of the file is empty; something else if the first line of the file contains some data. These three cases cover all the cases we talked about (empty and not empty files), and I think our friends know what they are doing. Of course I may be wrong, but that use of eof() seems to me fully ok. Regards, -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Ed, if reading a text file and extracting information from it is what you're trying to do, why not just use tmp = File.Load(Fname) File.Load is documented over here http://www.gambasdoc.org/help/comp/gb/file/load after loading the contents of Fname in tmp you can do your magic, without using an OPEN statement and a loop unless the file you're reading is a few megabytes, File.Load should be sufficiently fast to cover your needs. I am sure that there's more than one ways to skin a cat, and professionals didn't exactly drop out of the sky one day knowing everything about programming :) It takes practice and more practice and even more practice :) we all learn in different ways and we're all here to help each other :) Whether we are professionals,amateurs hobbyists or plain curious As they say in my country, One hand washes the other and both wash the face :) Hope this helps Regards, Dimitris On Mon, Apr 19, 2010 at 1:17 AM, Ed Clare Kelm twopil...@interisland.netwrote: Hi all: A couple of comments about the discussions below: 1. The test program was written with EOF at the start, because the actual program I am working on has this structure, for reading in multiple lines of text: WHILE NOT EOF(tfile) (bunch of code for reading the lines in and putting the data in the proper places) WEND CLOSE #tfile When that failed, I wrote the test program to see if I was actually sometimes getting an EOF immediately after opening the file, since the first thing WHILE does is test EOF. 2. Clearing label1 after every button click is just a little insurance. Given that things weren't working as expected, I wanted to make sure what I saw in label1 was new info, not something left from the previous button click. I know that shouldn't be necessary, because the IF-THEN-ELSE structure will always write to the label - but then there shouldn't be an immediate EOF either. 3. Using Fname like that is just a little habit I've developed. It allows me to try a different file by commenting out one setting of Fname and writing a new one, without erasing the previous one. And it makes the OPEN statement more compact and easy to read. It is also sometimes useful to put such equates all in one place, so it's easy to find and change parameters, rather than rummaging around in the code. You are correct, it is sort of a waste if I am only using the variable once. In my actual program, Fname also gets used when the database gets modified and the file then has to be re-written. I am not a professional programmer, so I'm sure I have some ways of doing things that make professionals cringe! Thanks again for thinking about my problem! Regards, Ed K. Doriano Blengino wrote: Les Hardy ha scritto: Doriano Blengino wrote: Les Hardy ha scritto: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. Just breaking in to say that a file with a EOL in it is not an empty file - it is a file with an empty line in it... Your correct, I agree completely, but the original code Ed supplied, ' IF Eof(tfile) ' cannot work , as it checks eof before a read. When I saw he was using eof() that way, and knowing empty files are not always empty, I thought I had found his problem, so I just added a bit of code that should have got around it. I am sure you will agree, that, whatever other problems he may have, he needs not to use eof() the way he is. Here is the original code. I think it is perfectly right: PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END If eof() is not checked *before* reading, then when? I see only two things I would not do (but it depends a lot). First, why use the fname variable, if it is used only once... second, why set label1.text if that .text will be anyway written shortly later? But, apart from these two very little things, that can also have some good reason, the rest of the code is the only possible, I think. Note also that label1.text can get 3 different values: EOF is the file is empty; if the first line of the file is empty; something else if the first line of the file contains some data. These three cases cover all the cases we talked about (empty and not empty files), and I think our friends know what
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
I use Gambas for nearly real-time work and it performs remarkably well, actually quite impressed. Far better than VB I have a data stream at 13.5 Kbps coming in from a remote modem requiring immediate work and turn around output. It might not seem like a fast stream, but the remote end requires a response immediately otherwise there are resends. It works! Gambas 1.0.19 graphical, FC4, samba Longest running time was about 420 days sans error. Some rules to follow: multiple core if you have it: good! remove unneed cron jobs. reduce overhead. turn swap off. Very clean efficient programming as possible -Fernando -- Original Message --- From: Doriano Blengino doriano.bleng...@fastwebnet.it To: mailing list for gambas users gambas-user@lists.sourceforge.net Sent: Sun, 18 Apr 2010 23:07:55 +0200 Subject: Re: [Gambas-user] Did anybody try to run stepper motors through paralel port Zelimir Ikovic ha scritto: I wanted to know how predictable and reliable GAMBAS is when a reaction to real-world events is required. Let say that Java RealTimeSystem is intended only for suitable operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM. So that means it depends on underlynig OS version ... Simply installing an RTS extension and renaming java.lang.Thread instances to javax.realtime.RealtimeThread will not turn the application into a real-time app. I just wanted to know what is Gamas reaction to real world compared under different underlyng OS. FreeBSD, OpenBSD and Linux are not he same. I understand but, let me say, your sample code had nothing to do with realtime... it was simply fast as much as possible, without any mechanism to ensure some kind of real-time response to some event. To only read a counter is not enough. I can run 4 stepper motors directly (no step+direction, but driving the phases directly instead) with a CPU more than 100 times slower than a x86 CPU. But this is possible using interrupts. Practically every OS can, in some way, use interrupts - gambas can not. So, the only way in gambas to do precise timing is to let it run alone, with maximum priority and privileges. Or, to delegate high timing precision to some external piece of software (a libray or a driver) which can take advantage of interrupts, or callbacks, or signals. On the other hand I think that gambas can, with tight loops, do delays like you did in the original source. Surely it is predictable enough to let you calculate in some way the correct amount of cycling to obtain the needed delay - the fact is that gambas will never be the only thing running on the system, and you have little control about that. The same problem of windows xp - if you want precise timing, you must obtain privileges, either for the program or using a driver. I must also add that, without particular precautions, linux is more predictable about sleep() than win2000 or xp. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user --- End of Original Message --- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] EOF problem
Dimitris: Oooh! That works! Weird. I'll have to write a little code to parse out my data from the single string variable, but that's a great work-around if I can't get EOF to work. Thanks! Ed K. Dimitris Anogiatis wrote: Ed, if reading a text file and extracting information from it is what you're trying to do, why not just use tmp = File.Load(Fname) File.Load is documented over here http://www.gambasdoc.org/help/comp/gb/file/load after loading the contents of Fname in tmp you can do your magic, without using an OPEN statement and a loop unless the file you're reading is a few megabytes, File.Load should be sufficiently fast to cover your needs. I am sure that there's more than one ways to skin a cat, and professionals didn't exactly drop out of the sky one day knowing everything about programming :) It takes practice and more practice and even more practice :) we all learn in different ways and we're all here to help each other :) Whether we are professionals,amateurs hobbyists or plain curious As they say in my country, One hand washes the other and both wash the face :) Hope this helps Regards, Dimitris On Mon, Apr 19, 2010 at 1:17 AM, Ed Clare Kelm twopil...@interisland.netwrote: Hi all: A couple of comments about the discussions below: 1. The test program was written with EOF at the start, because the actual program I am working on has this structure, for reading in multiple lines of text: WHILE NOT EOF(tfile) (bunch of code for reading the lines in and putting the data in the proper places) WEND CLOSE #tfile When that failed, I wrote the test program to see if I was actually sometimes getting an EOF immediately after opening the file, since the first thing WHILE does is test EOF. 2. Clearing label1 after every button click is just a little insurance. Given that things weren't working as expected, I wanted to make sure what I saw in label1 was new info, not something left from the previous button click. I know that shouldn't be necessary, because the IF-THEN-ELSE structure will always write to the label - but then there shouldn't be an immediate EOF either. 3. Using Fname like that is just a little habit I've developed. It allows me to try a different file by commenting out one setting of Fname and writing a new one, without erasing the previous one. And it makes the OPEN statement more compact and easy to read. It is also sometimes useful to put such equates all in one place, so it's easy to find and change parameters, rather than rummaging around in the code. You are correct, it is sort of a waste if I am only using the variable once. In my actual program, Fname also gets used when the database gets modified and the file then has to be re-written. I am not a professional programmer, so I'm sure I have some ways of doing things that make professionals cringe! Thanks again for thinking about my problem! Regards, Ed K. Doriano Blengino wrote: Les Hardy ha scritto: Doriano Blengino wrote: Les Hardy ha scritto: Hi Ed, I figured it out. First of all, depending how the text file was emptied/created, the contents may not be truely empty. Gedit for example leaves the 0A (end-of-line) character in the 'empty' file. This is recognised by eof() as a character, so, end-of-file is not found. I am not sure if this can be considered a bug in Gambas, but it does mean an eof() is only good for preventing read errors, and is not reliable for testing if a file is empty. Just breaking in to say that a file with a EOL in it is not an empty file - it is a file with an empty line in it... Your correct, I agree completely, but the original code Ed supplied, ' IF Eof(tfile) ' cannot work , as it checks eof before a read. When I saw he was using eof() that way, and knowing empty files are not always empty, I thought I had found his problem, so I just added a bit of code that should have got around it. I am sure you will agree, that, whatever other problems he may have, he needs not to use eof() the way he is. Here is the original code. I think it is perfectly right: PUBLIC SUB Button1_Click() DIM tfile AS File DIM Fname AS String Fname = /home/us/Documents/testdat.txt tfile = OPEN Fname FOR READ label1.Text = IF Eof(tfile) THEN label1.Text = EOF ELSE LINE INPUT #tfile, label1.Text END IF CLOSE #tfile END If eof() is not checked *before* reading, then when? I see only two things I would not do (but it depends a lot). First, why use the fname variable, if it is used only once... second, why set label1.text if that .text will be anyway written shortly later? But, apart from these two very little things, that can also have some good reason, the rest of the code is the only possible, I think. Note also that
Re: [Gambas-user] Did anybody try to run stepper motors through paralel port
Thank you all, in last few emails is answer! --- On Sun, 4/18/10, Doriano Blengino doriano.bleng...@fastwebnet.it wrote: From: Doriano Blengino doriano.bleng...@fastwebnet.it Subject: Re: [Gambas-user] Did anybody try to run stepper motors through paralel port To: mailing list for gambas users gambas-user@lists.sourceforge.net Received: Sunday, April 18, 2010, 2:07 PM Zelimir Ikovic ha scritto: I wanted to know how predictable and reliable GAMBAS is when a reaction to real-world events is required. Let say that Java RealTimeSystem is intended only for suitable operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM. So that means it depends on underlynig OS version ... Simply installing an RTS extension and renaming java.lang.Thread instances to javax.realtime.RealtimeThread will not turn the application into a real-time app. I just wanted to know what is Gamas reaction to real world compared under different underlyng OS. FreeBSD, OpenBSD and Linux are not he same. I understand but, let me say, your sample code had nothing to do with realtime... it was simply fast as much as possible, without any mechanism to ensure some kind of real-time response to some event. To only read a counter is not enough. I can run 4 stepper motors directly (no step+direction, but driving the phases directly instead) with a CPU more than 100 times slower than a x86 CPU. But this is possible using interrupts. Practically every OS can, in some way, use interrupts - gambas can not. So, the only way in gambas to do precise timing is to let it run alone, with maximum priority and privileges. Or, to delegate high timing precision to some external piece of software (a libray or a driver) which can take advantage of interrupts, or callbacks, or signals. On the other hand I think that gambas can, with tight loops, do delays like you did in the original source. Surely it is predictable enough to let you calculate in some way the correct amount of cycling to obtain the needed delay - the fact is that gambas will never be the only thing running on the system, and you have little control about that. The same problem of windows xp - if you want precise timing, you must obtain privileges, either for the program or using a driver. I must also add that, without particular precautions, linux is more predictable about sleep() than win2000 or xp. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] Some links I have found on The Net:
http://www.linux.com/archive/articles/40666 http://linuxfocus.org/English/March2004/article329.shtml http://www.linuxjournal.com/node/8481/print http://www.learnlinux.co.cc/gambas/ http://www.awce.com/gp3-gambas.html http://toko.baliwae.com/product_info.php?products_id=759 http://toko.baliwae.com/product_info.php?products_id=369 http://www.linux-magazine.com/w3/issue/26/Gambas.pdf http://www.linuxexpres.cz/software/gambas-visual-basic-pro-linux http://www.linux-magazine.it/Siamo-tutti-programmatori.htm -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user