|
|
That's too bad.
Writing to a serial port is the simplest part of it all. It takes no more than 10
to 15 lines of code to come up with an entire Console app that does exactly that.
And that is the only thing I can recommend under the current circumstances.
Good luck.
|
|
|
|
|
Ok let's try a different approach then.
I'm noticing the common problem being when data comes out the USB--either from the program or HT--and goes to the RS232 that's associated with the program. The common thing is the RS232 when the program is running.
Is there any reason why the RS232 wouldn't understand input?
Thanks for your time so far, there are a lot of things I wouldn't have guessed at had it not been for your input.
Take care,
Michael Fritzius
|
|
|
|
|
correction
Seems I somehow missed reading part of your last message.
my current impression is you confused yourself having two ports in your app.
matrix2681 wrote: //write line to USB port
sendtextfromrs232.Text += "\r";
serialPort1.WriteLine(sendtextfromrs232.Text);
//clear the text box
sendtextfromrs232.Text = "";
The above seems inconsistent, are you refering the right TextBox (or whatever
sendtextfromrs232/USB may be) ?
|
|
|
|
|
This is just the box that holds the text to be sent out the RS232 port. All it does is send it using the WriteLine() command and clear the box. The other method for this, the one that uses serialPort2 is the one associated with the USB port. It works the same way.
|
|
|
|
|
it works ?
if it works, we are done.
if it does not work, we must simplify till it works.
I am getting confused and I think so are you, seems to me you are sending the
content of the wrong box. So try a constant to end all doubts.
|
|
|
|
|
Nope, setting the writeline command to send out a constant didn't work.
I drew up a table to figure out what combinations really do and don't work. It shows that regardless of how I send data out the USB port--if it's the program or if it's HT--the RS232 in the program doesn't receive the data.
This sure is strange.
|
|
|
|
|
So are you saying now that your program is able to send after all ?
If so I recommend a long shower.
You told us earlier that receiving was no problem, transmission was the problem.
|
|
|
|
|
That's because originally I thought there was something wrong with transmitting out the USB port, since I was just using the program. After some testing with HT, I know that's not the case. Now I'm seeing the common thread being the program's RS232 port.
|
|
|
|
|
Hi all,
Ok here is the scenario. I wrote an application which reads information from a access database
and then the user has the option to export it to an MS word Document. This work 100% on some machines but troughs a Runtime error on other.
Here is a code snippet.
ApplicationClass wordApp = new Word.ApplicationClass();
//Error when creating event.
wordApp.DocumentBeforeClose += new Word.ApplicationEvents4_DocumentBeforeCloseEventHandler(wordApp_DocumentBeforeClose);
I almost don't see this being a code/logical error, may it be the version of Office
that differs on the PC's?
Thanx in advance
|
|
|
|
|
I have seen some issues, where if office is installed before the .net framework. The .net hooks into office don't get installed. So if you go into add remove programs and fix the install of office you should see a .net option that wasn't there before, if you istall the .net hooks then it should work for you.
Hope that helps.
Ben
|
|
|
|
|
Hi,
Thanx for the reply, I'm not too sure with the whole hooks concept.
But correct me if I am wrong, If I reinstall Office/Repair the installation
I don't have to do anything else???
If so I'll give it a shot and let u know!
Oh ja, one thing I forgot to mention is that only the events raises an error, I put them in a try/catch
block and the failed of cause but the word document still opened... Make any sense?
-- modified at 10:58 Thursday 26th July, 2007
|
|
|
|
|
When you reinstall / fix office there is a new option that talks about add .net components. You should see that if office was installed before the .net framework.
Ben
|
|
|
|
|
Hello,
In my application, I have to get a microsecond resolution for a timer.
Is it possible to do (on WinXP or Vista) ?
There should be high precision timers in kernel mode, but what is it and how could I get to them from .Net code?
All help will be appreciated.
Roman
-- Everything is possible, even the impossible! ^_^
|
|
|
|
|
Luc's article[^] is probably the definitive article on the subject.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Already read and tested, with this I can only get 1 millisecond resolution (Multimedia Timer), but I need 1 microsecond...
-- Everything is possible, even the impossible! ^_^
|
|
|
|
|
If you need to control timing that tightly, then you need a real time OS. There are several flavors of *nix that are, but windows is not.
--
You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
|
|
|
|
|
Yeah, but it should work in windows. I'm sure there's something like nanosleep in win32 kernel mode.
-- Everything is possible, even the impossible! ^_^
|
|
|
|
|
Kel_ wrote: I'm sure there's something like nanosleep in win32 kernel mode.
No, there isn't.
|
|
|
|
|
I am confident it is not; it probably is adequate for timing software events.
But who ever is interested in interfacing to the outside world,
or adding some special hardware to a PC, will ask things like the OP did.
And since there is no perfect solution available yet, MS is likely to continue and improve
on it step-by-step, as usual.
|
|
|
|
|
Use the System.Diagnostics.Stopwatch class.
---
single minded; short sighted; long gone;
|
|
|
|
|
Yeah, it's a good solution for measuring time, but for waiting (sleeping) I wasn't able to find a way to use it.
Thread.Sleep in combination with winmm.dll calls give 1ms precision only :/
-- Everything is possible, even the impossible! ^_^
|
|
|
|
|
Hi Kel_,
regular threads cant be scheduled at such precise moments. The scheduler basically
works with the system timer (thats around 16-20 msec) and it may be locked by something,
and hence take tens of microseconds to perform a switch; you can improve in two ways:
1.
the hacking way: give yourself a high priority, do a busy wait, then go for it;
as a general solution, it stinks; the other threads and processes wont like you and neither will the user in front of the PC; if you only need it occasionally (say you did cause an
external action to start and need to measure a micro-switch very accurately, then react on it),
you might even raise your thread priority to real-time. Dont do this for more than a few
milliseconds, or your PC will seem dead (and may even need a reboot). Even so, I dont
think you will succeed each time; at best I expect it to work most of the time.
2.
the normal way: write a driver; use interrupts, and run your ISR at one of the interrupt
priorities, then do postprocessing at one of the real-time priorities, then signal the user
(at a normal priority). This involves quite some work and knowledge; I have done this often
on embedded systems, never on a PC. And the more evolved the Windows version, the harder it
gets; they keep adding protections and barriers...
|
|
|
|
|
Thank you! This is helpful
So I should look for creating a driver, I'm interested in some examples... For the work and knowledge, I have my time and I like to learn.
Just for the context: my application is XNA flight simulator for a real world helicopter.
-- Everything is possible, even the impossible! ^_^
|
|
|
|
|
OK, I dont remember having seen a single CP article on drivers.
And IIRC the first thing you will need is called a DDK (Drivers Development Kit).
I also suggest you trim down your PC as much as you can: since you are going to reboot
your PC every time you hit the RUN button, better have the fastest boot time possible.
|
|
|
|