Tom_G_2010

If I followed the exchange correctly this is a bug in the C library and the function as designed isn't able to produce the result I need. But it is possible to evaluate and format the integer portion of the number separate from the decimal portion to get each to a fixed length and then concatenate the result for my output string, yes? using ans = string.format("%02d", val1) .. '.' .. string.format("%02d", val2) I will try this after I get off work today and follow up here to let you know how it works for me. THANKS!!!

Scott, Thanks for pointing me to the syntax references I'm experimenting with various things now. Still not able to get a leading zero on there via the format function but that may just be my poor programing skills. I found one delphi reference on how to do it but the syntax does not seem to be supported in lua as it causes the script to fail. Until I figire it out I am evaluating the varable with an if statement to determine when it goes below 10.00 and if so I am concatenating a leading zero onto the string to be sent. If you have any other thoughts on this your assistance would be greatly appreciated. In the interim I'll keep plugging away. Thanks! Tom G.

Scott, Thanks! That takes care of the characters following the decimal. I'm still dropping the leading character below 10 though. So, 12.3000... volts shows as 12.30 but 9.3000... shows as 9.30 not 09.30 Any further thoughts on the integer portion? Tom G.

I am working on a lua script to monitor several values from P3D and send them to an Arduino via serial com as strings. I need the values to be fixed in length in order to interact with existing Arduino code monitoring the com port . For example, for my bus voltages I have a function to round the values to two decimal places but this removes any trailing zeros. And of course I loose the leading zero when the voltage drops below 10. So while 28.3157... results in 28.32 which is what I want, 28.3000 results in 28.3 but I need it to be 28.30 And, on the other side I would need 9.3157 to be 09.32 From what I've read in the lua docs and online I think I should be able to accomplish this with "string.format()" but I can't seem to make it work and the examples I'm finding aren't helping. Will string.format accomplish what I need? If so, what is the correct syntax? If string.format is not the answer any ideas on how to accomplish this would be greatly appreciated. Thanks! Tom G.

Paul, Thanks! My plan is to load up P3DV4 sometime after FlightSimCon. My PC drives are on sleds and I just ordered another pair of sleds for this. I'll be setting up an alternate set of drives with P3DV4 so I don't mess up my current P3DV3 rig. I appreciate your advice and the approach you suggest. This looks like it may be on the top of my summer project list. I'm sure I'll have plenty of questions and I'll try to post progress updates as well. Again, Thanks! Tom G. PS: If your interested you can check out my sim pit build at https://www.facebook.com/mycessnasim/ or http://www.mycessnasim.info

First, full disclosure, I'm not a programmer. I am self taught to some degree with C++ (at least the subset of it that Arduino's use), a bit of VB and some basic LUA and VBA. I've been a long time FSUIPC user but just recently noticed the FSUIPC Client DLL for .NET subforum and it caught my attention. I need to solve for a problem if I am to make the move to P3DV4 and I'm trying ot figure out of this might be a starting point. My Cockpit build (A Cessna 172) uses Arduino cards for everyting from my Avionics stack to my wet compass and air speed sensatve vents. They are at present interfaces to P3D via a discntinued program (Link2FSMulti) that passes many of the P3D offsets to the Arduinos via serial USB as a simple set of text strings (for example air speed might be <T090) that I can read and the Arduino's in return control codes that the app coverts to P3D offsets. The app allows me to select which offsets I want to pass and to what serial port. The app is unfortunatley not compatible with the new P3DV4. As I search for a replacement app I am finding many that allow for some form of I/O between P3D and the Arduino but most do so by loading their own code onto the Arduino that takes over the Arduino and creates an interface that the developer thinks is ideal. I am finding that most fuction far different or in a few cases fall far short in fuctionality to what I have developed. As an example they will control the 7 segment displays on radios and allow tuning but they would not allow me to replicate the 32 channel memory that I have coded into my current radios. So I would have to toss a great deal of my current code in the bit bucket and give up on functionality to use those apps. To cut to the chase I want to develop a very basic interface that allows me to pass a selected set of offsets (if possiblle in the form of a very basic serial strings as noted above) from P3D to specific USB serial ports and then via those same ports pass serial strings back that interface would pass back to P3D as offsets. I was pondering writting a big LUA script to do all this but, as I said cae across this forum and I am wondering if this might allow me to write a somewhat more userfriendly VB app that would accomplish what I need. Any thoughts or advice would be greatly appreciated.

Arrggghhhh!!!!! I just noticed why and feel really embarrassed for all this activity over what may only be a case sensitive issue. I declared speed=9600 but my com.open was looking for Speed

Pete, SERIAL DATA FLOW PROBLEM SOLVED!!! My original com open statement in the Lua script looked like this: speed = 9600 handshake = 0 ArdComPrt = com.open("COM8", Speed, handshake) Just now to strip it all the way down and eliminate any other problem sources I took out the variable declarations and ran it as follows: ArdComPrt = com.open("COM8", 9600, 0) That works! The Com Port opens and the data keeps flowing. Should that have made a difference? Should the 9600 or 0 been in quotes when I declared them? I am running into some other problems with my LVars but I'll start a separate post about that If I am unable to solve those issues on my own.

A user on an Arduino forum pointed out that the Arduino is designed to do a reset any time that a connection is open via the USB port. I guess they did this to make uploading code to the board easier for users. However, I'm told this may be what is stalling my serial port. I am reading up on some ways to disable that reset. But I am also curious why the Arduino IDEs serial monitor doesn't cause the same problem. If I connect it and the port resets why then does the serial data resume. I'm asking out on the Arduino forum to see if there's some sort of string I can return to the Arduino from the lua script to wake it up.

Pete, I'm doing some reading on a couple Arduino sites trying to figure out what the Arduino is expecting. I haven't found much yet. On the official Arduino sites reference page I don't see any mention of flow control and the only serial parameters I seem to have control of are data bits, parity and stop bits. By default it's set to 8N1. I can configure the data bits from 5 to 8, parity None, Odd, or Even and, stop bits 1 or 2. I haven't found anything on flow control yet but I've tried all four options from com.open in my lua script and none resolve the issue. I've also posted out on one of the Arduino forums to see if anyone there might have some additional information. Tom G.

As an additional test I removed event.com line from the script so that the only thing affecting the com port was com open and the data still stops flowing so it appears to be the com.open that is stalling the port.

Pete, To clarify what the serial monitor is showing their is a 2 second pause between 41 34 35 0d 0a and 41 34 36 0d 0a that I failed to note in my reply above., I started to edit my lua script per your suggestions and before I got too far I discovered something. Prior to this I had been running the serial monitor program (Device Monitor Studio) only briefly just to confirm the strings being sent by the Arduino. For this round of testing I left it running and observed it as I ran the lua script. For testing I have the lua script assigned to two buttons. One to launch it and the second to kill it. I was watching the serial monitor during this round of testing and noticed that the data stream coming form Com 8 (the Arduino) stops any time I launch the lua script. Having discovered this I did it a few more times just to confirm I could replicate it and I can. When it occurs I can jump start the serial port again by killing the lua script and turning the Auduino IDE's serial monitor on and then back off. As soon as I do that the Device Monitor Studio shows the data flowing again. But, if I launch the lua script the data stops. Any thoughts on what would cause that?

Pete, I removed com.test as suggested and it didn't make a difference. I've also changed the Lua script to use event.com. Another user sent me a code example from there setup that is working for them and it also used event.com Here's what I'm doing to test this now. Ardiono test code same as before: void setup() { Serial.begin(9600); } void loop() { Serial.println("A45"); delay(2000); Serial.println("A46"); delay(2000); } Lua Script: speed = 9600 handshake = 0 ArdComPrt = com.open("COM8", Speed, handshake) if ArdComPrt == 0 then ipc.display("Could not open ARDUINO Com Port") ipc.sleep(1000) ipc.exit() elseif ArdComPrt ~= 0 then ipc.display("ARDUINO Com Port OPEN") ipc.sleep(1000) ipc.display("") end function ArdData(ArdComPrt, datastring, length) if datastring == "A45" then ipc.writeLvar("L:kma26SelectorKnob_pos",1) elseif datastring == "A46" then ipc.writeLvar("L:kma26SelectorKnob_pos",2) end end event.com(ArdComPrt, 10, 1, 10, "ArdData") Using a serial monitor program to watch the port I see the following repeating in Hex 41 34 35 0d 0a 41 34 36 0d 0a So, the A45 and A46 are each being sent with a Line break and Carriage Return. But still no joy. The Com Port indicates open but the script doesn't appear to be detecting the serial traffic. I've also switched out Arduino cards and serial ports. Any further thoughts?

Pete, Thanks! I like the idea of using a terminating character. I'll be sure to try that. With the variable length of the strings it sounds like that would be the cleanest way to deal with it. I'll get back to you with my findings on com.test, read, and readlast. Work is getting a bit crazy though, I just got pulled into a multi day fire dril, so it may be a few days, but, I'll be sure to post my progress as soon as possible.

A good question and my honest answer is lack of experience. The received strings will have a minimum of 3 characters similar to the test string "A45" which will active Comm 1 xmit. However, some of the codes will be followed by 1 to 5 digits to do things like set a radio frequency or select a DME, etc. So I I could receive the first three characters all at one time consistently and listen for additional depending on the code string sent. I will need to do some reading and research on the terminator to figure that out. The serial.println is supposed to send a line feed. If that might be messing it up I'll try a regular serial.print for sending the strings. I did a couple basic test to confirm the Com port and it does appear to be correct, Com 8. For example knowing that it can only be used by one program at a time I turned on the Arduino IDE serial monitor and could see the test strings being sent. With it on the lua script could not open the com port. I did the reverse and opened com port 8 with the lua script and the IDE could no longer access Com 8. So, I think that shows I've got the correct Com Port, yes? I also downloaded a program to monitor USB serial ports and when I set it to watch Com 8 I see the test strings as traffic on the port. Assuming the Com Port is correct and the data can be seen on the port by the monitor, any further thoughts on trouble shooting steps that I can take? Thanks, I'll modify the script accordingly. I'll read up on the use of event.com and modify my code. Thanks for the reply! I'll do some more work on this and come back with any further questions.