I'm making a heart rate analyze, but I'm having a real problem with that. When I'm press to start the programm doesn't work, so, I've press to stop the running program and it shows me in the section where it's ready to close or finish the connection:
Error 5002 occurred at Init.vi. Unable to establish connection with
Arduino. Please ensure that you have selected the correct COM port
and that you have flashed the Arduino with the correct firmware.
This error code is undefined. Undefined errors might occur for a
number of reasons. For example, no one has provided a description for
the code, or you might have wired a number that is not an error code
to the error code input.
Additionally, undefined error codes might occur because the error
relates to a third-party object, such as the operating system or
ActiveX. For these third-party errors, you might be able to obtain a
description of the error by searching the Web for the error code
(5002) or for its hexadecimal representation (0x0000138A).
This is my VI diagram:
And this is my control panel:
And the connections to my arduino:
So:
how can I solve this problem?
Where can I find more information to get this
Thanks for your help, but I'm new on this world (Arduino and Labview)
Follow the suggestion given in error message. First of all, make sure that you could communicate with Arduino using some simple serial line terminal, like RealTerm, or HTerm. In case if you couldn't send any command using serial line terminal, check out which firmware do you have on Arduino.
This is the way, how you could troubleshoot this issue...
You can ignore the second and third paragraphs of that error message; they're generated because the Arduino VI's you're using are generating a custom error code that they haven't registered with the LabVIEW development environment, so its automated error handling doesn't know what they mean. The information you need is in the first paragraph though.
As kosist's answer says, the first thing to check is that you can communicate with the Arduino at all. Before you even start with LabVIEW, have you tried using the Arduino IDE to program your device with a simple program like the 'blink' example?
If that works, then the next step is to make sure you've programmed your Arduino with the firmware it needs to communicate with the LabVIEW VIs you're using (can you link to where you got them from?) and then try a much simpler test program in LabVIEW - again, just get the Arduino to do something simple like turn the buzzer on and off. If you hit a problem with any of those, I suggest asking a new question with details of exactly what you tried and what errors you saw.
Related
I've been having to come back to a modem I have and sending AT commands to it, and I need to do this programmatically. Sending AT commands works fine if using Minicom, but when using any kind of programatic method it's just super unreliable. I've tried echos and redirection with bash, the atinout program, and the pyserial module in Python, but no matter what sending and receiving commands is iffy at best. It is very rare that I attempt to run the same AT command twice and get consistent output back. I'll get the complete response one time, but then a partial response the next, or maybe no response.
Admittedly I don't know much about serial, so maybe it's my hardware, or maybe the protocol for reading and writing to serial is just unreliable. Can someone please explain how, in general, reading and writing output over a serial port may be unreliable, and any good techniques or libraries to help guarantee a stable flow of reading and writing?
There was another service on my system called ModemManager that was consuming the serial device at the same time I was running through my commands. Once that was disabled all of my programmatic efforts started producing reliable IO to the device.
I have a custom board with an STM32WB55CEU (512K Flash) that is failing to start the BLE stack on CPU2 in the function SHCI_C2_BLE_Init(). I believe it's failing this function because it failed to load the BLE firmware (stm32wb5x_BLE_Stack_full_fw v1.13.0) correctly. Whenever I try to load the firmware I get an error at the end saying FUS_IMAGE_NOT_AUTHENTIC or FUS_STAE_IMG_NOT_AUTHENTIC depending on whether I try it from the command line over USB or through the GUI over SWD. I can delete the firmware image without error and my FUS appears to be up to date and running before I attempt the update.
Firmware Update Screen from STM32CubeProgrammer
Security Configuration Option bytes
I've also tried deleting the firmware by changing the RDP register from AA to BB and back. I still get the authentication error. This only happens on about half of the boards that I've loaded (13 out of 25). I feel like there is an address of setting somewhere that I'm not setting correctly and since all of the other posts I can find on this issue use the Nucleo with the 1MB flash part I'm not sure if my parts settings should be different. I am putting the FUS and BLE firmware at the correct address for my part according the v1.13 release notes.
Any help to get past this authentication issue would be appreciated. Thanks.
I had no problem uploading codes to my arduino for a while, then I found some weird issue. I wrote some code in c++ and imported to arduino sketch.
When I tried to use C1222_EPSEM class (see picture above), i got programmer not responding error and was not able to upload the code. However, when I commented that class out, I successfully uploaded the code without any problem. I have no clue why this happen. Any idea?
it is spamming the serial, then the PC's and USBtoSerial chip's buffers are still full after the reset sent by progroammer PC, then he read a bit of this buffer, it is not the response expected, and voilà.
Please DON'T use image for code
Folks
I have two protoypes (say prototype A and B ). Both the prototypes uses Telit GSM modem .
I am using the common SIM to work with both of them.
Problem: If I use the sim with prototype A , AT+CGDCONT, AT#GPRS=1 these commands work perfect . But with Prototype B using the same sim AT+CGDCONT, AT#GPRS=1 don't work .
AT+CGDCONT always echos "operation not allowed" .
So is there any way i can debug this issue ?
Thanks
Ak
You might want to ramp up the error detail. Try setting:
AT+CMEE=1
Most common GSM Modems with a standard AT Command set will then output proper error codes. I have found often such generic messages are then replaced with much more detailed error codes.
Swap the GSM modems and see if the fault moves with the swap. If it does, dump the faulty modem (i.e. replace it to see if that cures the problem). If not the problem may be with your prototype.
It is difficult to guess the reasons. It could be that module B is faulty.
Even though you think both devices are identical, there are settings that might make them different. I remember Telit have commands like AT#SELINT and you have to check whether those settings are the same for both modules. There are a couple of other settings like this which persists after power cycles. If you don't know how to track those differences, you can always format the modules.
Go to Roundsolutions Download section and download the firmware for the module and burn them in using the tools in the same website. After that is done, you will be sure that they are really identical.
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
Has anyone experienced this before? If so what did you do to fix/workaround the problem?
Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
Flow control is not used.
Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.