I got your message regarding the GRBL issue... I think the biggest issue revolves around timing accuracy. You mentioned that the arduino can send out pulses in the microsecond range... and indeed this is too fast for Grasshopper to parse. In fact, you aren't actually reading in data (using Firefly) at 1ms intervals even when you set the timer to 1ms... the time interval that is set is the time delay that the thread waits after the entire solution cycle has been computed before starting a new cycle. Say for example it takes 30ms to compute a single solution, then your approximate frame rate would actually be 31ms. And I say approximate because the solution cycle depends a lot on the graphics redraw cycle (among other things). So, it's really variable.
To get back to your question... if you actually started sending data over in the microsecond range, then you will flood the buffer in Grasshopper and cause it to crash. You could theoretically store the arduino output in a list (on the arduino side) and only send it over to Grasshopper every 25-50ms. However, you only have so much memory on the arduino chip and it's possible depending on how much information you're trying to store/send that it could fill up. The best possible solution would probably to try to come up with a event driven strategy. For instance, the arduino continues to store the arduino data until it receives a message from Grasshopper saying it's ready for the next packet... it then sends the packet, clears the buffer, and starts the cycle all over. The stepper firmata tries to do this... although there are some weird quirks currently that I'm trying to work through. Anyway, I hope this helps to some extent. Given the speed at which you're sending data... it's going to be tricky to handle this in Grasshopper without saving something in a buffer... because the Grasshopper timing accuracy has some variable latency that will be difficult to overcome.
Andy Payne
Hi Matthew,
I got your message regarding the GRBL issue... I think the biggest issue revolves around timing accuracy. You mentioned that the arduino can send out pulses in the microsecond range... and indeed this is too fast for Grasshopper to parse. In fact, you aren't actually reading in data (using Firefly) at 1ms intervals even when you set the timer to 1ms... the time interval that is set is the time delay that the thread waits after the entire solution cycle has been computed before starting a new cycle. Say for example it takes 30ms to compute a single solution, then your approximate frame rate would actually be 31ms. And I say approximate because the solution cycle depends a lot on the graphics redraw cycle (among other things). So, it's really variable.
To get back to your question... if you actually started sending data over in the microsecond range, then you will flood the buffer in Grasshopper and cause it to crash. You could theoretically store the arduino output in a list (on the arduino side) and only send it over to Grasshopper every 25-50ms. However, you only have so much memory on the arduino chip and it's possible depending on how much information you're trying to store/send that it could fill up. The best possible solution would probably to try to come up with a event driven strategy. For instance, the arduino continues to store the arduino data until it receives a message from Grasshopper saying it's ready for the next packet... it then sends the packet, clears the buffer, and starts the cycle all over. The stepper firmata tries to do this... although there are some weird quirks currently that I'm trying to work through. Anyway, I hope this helps to some extent. Given the speed at which you're sending data... it's going to be tricky to handle this in Grasshopper without saving something in a buffer... because the Grasshopper timing accuracy has some variable latency that will be difficult to overcome.
Jun 15, 2014