|
The code I put up before is almost the whole thing, short of a few housekeeping snippets like clearing the textbox when the user clicks on it. I think this message you sent was sent before you saw the code though.
When both ports are examined by HT (not using my program at all), the ports can talk to each other just fine, both ways. So the hardware is solid.
When my program is running and sending data out one port, with HT receiving on the other, HT can receive all data, regardless of if it's looking at the RS232 or the USB.
The problem shows up when I try to use only my program. Data can come in the USB port, but data sent out the USB port either gets garbled, or is misunderstood by the converter or something else.
(also I tried reversing the cable, and it still works in the same way listed above, so it is in fact a null modem cable, like what I need  )
I know this seems really weird, and it seems like it SHOULD work... but for whatever reason, a transfer from USB to RS232 just ain't happening in my program.
I just thought of something... do you think that including the driver DLL that came with the converter as a reference would help? I mean it's obvious that HT has the ability to get and understand whatever is coming in the USB port. Could it be that HT is making use of something that I have to tell my program to make use of the same DLL or something?
|
|
|
|
|
Give this a try:
replace both lines containing port.WriteLine(...) by port.WriteLine("abcdefghijk");
and test again.
|
|
|
|
|
|
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.
|
|
|
|
|
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
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...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
