I am currently experimenting with Strings and reading data from serial on an Arduino. But i find that when you are using Strings to read data from the serial or to compare it to another string, it is extremely slow(takes about one sec). It changed back to the normal, fast speed when i am using chars to read from serial.
Why is it so slow?
thanks
According to this link,
https://www.arduino.cc/en/Serial/ReadString
Serial.readString() reads characters from the serial buffer into a
string. The function terminates if it times out
here is the timeout method description
https://www.arduino.cc/en/Serial/SetTimeout
Related
We are running into an issue with UIPath that recently started. It's truncating strings, in our case a base 64 encoded image, at 10k characters. Does anyone know why this might be happening, and how we can address it?
The truncation appears to be happening when loading the text variable base64Contents. Seen in the photo below.
base64Contents = Convert.ToBase64String(byteArray);
As per the UiPath documentation there is a limit of 10,000 characters. This is due to 'the default communication channel between the Robot Executor and the Robot Service has changed from WCF to IPC'
https://docs.uipath.com/activities/docs/log-message
Potential Solution
A way round this could be to write your string to a txt file rather than output it as a log. that way you are using a different activity and the 10,000 character limit may not apply.
I'm trying to read data from the Yost Labs 3-Space Sensor Nano into LabVIEW via an NI MyRIO (1900). I was able to set up a sequence that communicates with the sensor through SPI. However, every time I run the program, it just spits out a single value of 255.
I think understand that I need to include something that allows all the bytes to be read. I just don't know how to go about it.
As an example, I'm trying to read the gyros (0x26) which have a return length of 12 and is a vector (float x3).
Here is my labview code
and here is the manual for the sensor. The commands I'm using are on pages 29-33. In the image, 0x2B is 'read temperature'.
Any help would be greatly appreciated! Thanks :)
Edit: i had messed up the wiring so now the output jumps between ~35 to 255. I'm still having trouble getting all 3 gyro values from the SPI read.
Quoting from Joe Friedrichsen in his comment:
The express block that resets the sensor is not guaranteed to precede the loop because there is no data flow between them. The LabVIEW runtime can see two independent and parallel groups and may choose to execute them simultaneously (which on the wire might mean reset comes between loop commands) or in "reverse" order. Add a wire from reset block to create a terminal on the loop.
Here's a picture of the fix.
You may wish to consider stringing the error wire through your program and wiring it to the stop terminal of the While Loop. Currently, your loop will keep running even if there's a fault in your hardware. Using the error wire would eliminate the need for the flat sequence structure.
I have a client and a server code. I create ffmpeg process on
both ends and use pipes to communicate with ffmpeg. I passed an RGB data and read HVec out , send that the client and do the opposite. basically I'm streaming HVec, The problem I have with the pipes is The buffer size are too small so I have to do a bunch of file read operations from the pipe . and it's really slows me down. for example if I have to read 100 bytes , function reads 20 bytes. so I have to loop five times to read hundred bytes . of course these numbers are made up . actual data size I try to Read is 1080*1920*4=829400
1 is writing to a socket and communicating via sockets a better choice.
2 would name pipes work better?
I know third option is to use avcodec lib but I'm trying not to do that
I use a command line ftp (the one on mac osx) inside some application I developed.
The thing is, this application will be used on very slow internet connexions.
In the actual configuration, I use the stdout with hashes to determine upload progress this way:
I first get the exact file size.
I activate hash output in ftp
3 I then simply count each time I read something from stdout how many hashes have been printed, and add them to my interal counter
4 multiplying this hashcount by 1024 bytes, I get the transferred data over the total data to caculate percentage.
This works but isn't as fluid as I would like it to be..
The final results jumps 20-30% at a time and 'waits' for 2-3 seconds between each stdout.
on large files with a fast internet connection, let's say a 100mb file over a 50mbps connection, this is very fluid..
Is there a way to tell ftp to output the current upload state more often? like based on a time interval, every 200ms or so... ?
I've checked out a few of the forum posts here and can't find quite what I'm looking for. Suppose you are reading in a text document via Ruby. I understand the stream is essentially the characters coming in byte by byte. What is the purpose/best practice of buffering in this case? My book shows plenty examples of the buffer being utilized, but no real description of what the buffer is or why it even exists. What should I be considering when setting the buffer? For example, the book illustrates the following method as:
read(n, buffer=nil) reads in n bytes, until the bytes are ready
I don't understand what the statement "until the bytes are ready" means. Does the buffer play a role in this? Please feel free to point me to another place where this is explained, I couldn't for the life of me find it on my own.
IO can be not only file, but a network socket. and in networks you regularly have a situation where you are ready to process more data, but the remote side have a pause in data sending.
(You usually see a progress bar or a spinner element in your browser in these cases)
So, if you are using regular files, the bytes are always 'ready'.
The Picaxe book for IO#read says:
Reads at most int bytes from the I/O stream or to the end of file if int is omitted. Returns nil if called at end of file. If buffer (a String) is provided, it is resized accordingly, and input is read directly into it.