I am very interested in getting this to work, but the engine gives me problems with the "str_for_int" it says undeclared identifier. There isn't anything in the manual.
The "SHOW" and "WWRAP" flags apparently don't work also (when I commented out the str line. I changed show to visible and it worked, but I don't know what to do with the wwrap so commenting it out seemed to work. (using a7)
Any ideas?

You need to be using at least A7-7.50.
And if your using lite-c free, I dont know what its version is.

SHOW requires 7.66, if you are using an older version, replace it with VISIBLE.

'str_for_int' requires 7.50, if you are using an older version, replacing it with 'str_for_num' SHOULD work.

WWRAP requires 7.60, if you are using an older version, just delete the WWRAP flag.
But note that and text added to that TEXT panel will now only bo on the first line,
and will no longer auto-wrap to the next line when 'this' line is full.


Does anyone out there know what engine-version lite-c(FREE) is ATM ??

Awesome, thanks man. This will really help me a lot.
I've apparently been neglecting my updates since I've put some of my projects on hold for a while.

:-)

Ok, at first I was going nuts thinking it wasn't working with the exact same setup and code I was using, but I apparently found an issue. (I am using an FTDI usb serial chip making COM8 a virtual com port through my usb, works fine though)
I put in the code and test it with the arduino software and test that I am getting serial data on the right com port.
I open A7 and it works fine.
Here's the tricky part:
if I unplug my USB serial cable and plug it back in, A7 will not recognize it... I know the code is working because I see my rx light up at the proper interval. A7 won't connect until I connect and disconnect with another software (I use my arduino "serial monitor" for this. I connect, disconnect a few seconds later then run my code in A7 then it works again)
Any ideas on how to fix this problem?
Can anyone else verify this on their machine?

Im not clear, but are you leaving A7 running DURING the unplug-replug process?

Also, try testing it using non-arduino software. (Say Hyperterminal on XP and below.)
It may be re-connecting on a different com port and the arduino software prolly doesnt care.

I did all my testing with hyperterminal <-> A7, a real serial port at the hyperterminal 'end'
and a generic usb stub that run with just windows built-in drivers at the A7 end.
Sometimes swapped over to ensure it worked the same way in both directions.

Another possible issue may be if the drivers are still initiallising when
A7 is started, it may not see that serial port yet.

I'll be listening...

I am hitting esc to close the port and program properly before unplugging.

Arduino software is setup to look at the same port number every time. I also checked through my device manager and it has "serial com port (COM8)" listed before I run A7.

The ftdi drivers seem to be working OK, I don't have an xp machine I can test on at the moment.
I thought it could just be taking a while for the drivers to load, so I gave it a decent amount of time before running my code. Also, if it's shown up in device manager, it should be loaded already. It is trying to look at the com port, I see my LEDs on my board light up as if it's talking to the PC the same way it does when I'm establishing a new connection, it just doesn't show any code coming in from the board.
Maybe I should test it for outgoing code to the board, send a number and if received light up an LED on a pin. Can I send using this code too?
If you can't reproduce the effect the same way, maybe it's a Win7 thing, I'll try setting up an older machine and test it the same way there.

edit: to test the output method I would assume I use port_write_bytes while checking to make sure port_read_status is true. does anyone have a sample of this for me to check, I have this so far used in the while loop


Still not sure about if Win7 is the problem though

The best my memory can supply this is ALMOST correct.

All that looks wrong to me is the buffer needs to be a null-pointer.
So the port_write_bytes should be port_write_bytes(hPort, &testz, 1, 500);

Otherwise the logic and syntax looks fine to me.

As for it being a windows7 issue, Ive not had access to anything higher than XP-sp3.
I think someone tested it OK in Vista, but I think your the first Win7 person.
But seeing as it works happily bufore the plug-unplug thing, I would say its a
Win7 'quirk', and I cant do anything about it myself till I get around to
building a Win7 test-box.

But I'll keep me eye here in case anyone comes up with anything I can tweak without win7.

I'm actually running Win7 beta, I just got the ultimate disk, so I'll be installing that soon. It has an xp compatible mode built in, just in case it is the problem.

I noticed the syntax on reading the var, I guess I didn't think to put it in the write (&testz), thanks. I'll be testing both issues soon and post back my findings.

I wanted to come here for some fun ! Who can give? Thank you !

wubinuu@gmail.com

This is a great contribution to the GS community, thanks.

After tested it with your previous example code on my vista machine. I met two minor problems,

First, when port_open_read/write/readwrite my existing com port, it only suceeded once, after my exiting the script and re-run it again, the port_open_xxxx command seems not to work anymore. But when I close the SED then reopen the SED, load the script, run it. It works again. (and Yes, the first script run only)

Listed bellow is my modified script from your example,



Maybe the port_close needs more time to finish its operation before A7 closing ?

Second, the port_open_xxxx command seems not to be able to open the port number larger the 9 (e.g. 10, 11, 12 ....). Is there a way to get around this problem? since I use a virtual com port through a usb converter, it is very easy to get a virtual com port number larger than 9.

I apologize for my bad english, your kindly response will be much appreciated.

Again, thank you for your wonderful contribution. I really think conitec should include your work in next update.