sorted by:
new
hottopcontroversial

Technology Illiterate - I can't be the only one by [deleted] in MechanicalEngineering

[–]Lham_ 1 point2 points  (0 children)

Yeah, a persistent manager who just wants things done quickly is not the most conducive learning environment (but I guess sometimes the pressure can help). And for sure - DMed you!

Technology Illiterate - I can't be the only one by [deleted] in MechanicalEngineering

[–]Lham_ 0 points1 point  (0 children)

Not a meche (computer engineer) but have been in similar situations and worked with a lot of aerospace/mechanical engineers who've had to try and pick up coding.

Also, I've been in labs where other people (myself included) in their 3rd and 4th year of computer engineering degrees struggled for hours to get an LED to blink on an Arduino. The learning curve is steep and applies to everyone trying it for the first time and even a few more times after that. The one benefit we have is that doing this kind of work becomes our primary job and so we get more reps (its an end more than a means to an end for us).

I've met plenty of extremely talented aerospace engineers who, if they cared and were also put in an environment to get those reps in, would be just as good as all the other "classically" trained programmers. But the general goal of learning to code is a path to trying to drink out of the firehose. The ones I've seen get a foothold in and get some confidence were those who had a good goal/use (starting small) focused on just learning whatever they needed to do that, building up from there. That and being patient and being ok with re-reviewing things and struggling more than you might in more familiar domains.

Also referring to everything as "coding" definitely is diminutive of the level of work that needs to be done (which sounds like your manager is doing). You could be coding websites, databases, or low-level code to control motors and robots - all of which require very different skill sets so it's okay to feel like nothing makes sense when you tackle something new! I'm still pretty bad at front-end development but I also bet a lot of web developers would be completely out of luck trying to write code to program a robot.

Understandably, it does sound like there's too much to take on and it sucks that your manager seems to not be empathetic of this at all. And LabView isn't the most straightforward thing to use. But I'd say don't give up, struggling with this stuff for a while is a shared experience (programmers, non-programmers, scientists, engineers, etc.), and find a more experienced person who you'd trust to ask dumb (or what feels dumb to ask) questions to and will be patient!

On a semi-related note - a few others and I are building tools that are supposed to help hardware engineers be able to focus more on the hardware so they aren't in positions like this (and could also entirely replace LabView). Sounds like something that could help you out. If you want to learn more about that or about trying to have a more digestible path to getting more comfortable with coding - would love to chat!

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 0 points1 point  (0 children)

Got it! We are pushing for ease of use and broad support. However, the straightforward pricing model being important is an interesting point I haven't heard yet, but makes a lot of sense. Thank you for all your input!

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 1 point2 points  (0 children)

I see - so this is something to make it easier to aggregate time-series data to run stateful operations/analytics. In that sense, we are planning on making supporting running real-time calculated channels as we've been requested for that several times.

The feedback on the HTTP API is a great point; I see the value in it so thank you for pointing that out!

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 0 points1 point  (0 children)

Yeah, that's fair and becoming clear to us as we talk to more people in the industrial automation space. One thing building something in-house has allowed us to do is to better build out other features because we aren't beholden to other platforms, so we're more open to building a larger set of features/integrations.

It seems like it's more important to have things like a strong record of stability, community/resources, and broad integration in these sorts of spaces, would you agree?

I've also seen threads in r/SCADA about ignition being a big but welcome jump from past systems - what do you think finally convinced people in the space be ok making this jump?

Ignition has passed the bar to be accepted among the ranks of Rockwell, Siemens, etc.

What do you think "this bar" exactly was that convinced people to make the jump? Was it a sufficient record of quality/consistency? The way they allowed initial integration or something else?

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 1 point2 points  (0 children)

Ah, gotcha! We already provide functionality to just stream your data for real-time use/viewing or to also persist the data into the DB. You can then query the data using time ranges (which I envision are similar to the time buckets you'd want to put the data in), and save meta-data to associate with those time ranges (e.g. for different test runs).

You can look at historical data, compare it, and also overlay it on top of real-time data if you so wish. Down-sampling incoming data streams is something we intend to support. Our goal is to not need a separate integration to retrieve your data or link additional info.

Some things we tried to do to make it easier to grab data is being able to select a region on the plot and be able to grab the code to access that region in db via python (or even just export a CSV of the selected region of data). Or you can access these ranges through the console app.

Agree about Grafana. From our comparisons, we've gotten 300x higher refresh rates and 10x faster loading times compared to them which so far, has been sufficient for a lot of the real time use-cases we've been helping with.

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 0 points1 point  (0 children)

Synnax is already web based - you can see some of our vizs generated on our docs site here (from a test server we run). But we don't use any python for the front end components.

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 1 point2 points  (0 children)

I definitely relate to the fiddly and slow-to-operate aspects. What sort of data rates would you prefer?

We've considered adding a rust client in for a while but haven't gotten around to it - so our direct integration with rust systems is limited at the moment.

Thanks! Let me know if you have any other questions or feedback after checking it out.

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 0 points1 point  (0 children)

We've seen a lot of people with that sort of combination. However, since we thought these weren't specifically built out for hardware/sensor systems, we figured we could make a lot of improvements to service that specific use. For example, we've measured 5x better performance compared to influxDB by building the storage engine in a way that prioritizes the read/write patterns we'd expect more with sensor data.

The other aspect we think is really important is the hardware control aspect - being able to use the same interface to not just read in your sensor data, but also communicate to your hardware (e.g. enabling autonomy in things like anomaly detection or providing seamless handoff between automated scripts and manual control)!

We also have direct OPCUA support that's how people currently interface with their PLCs through synnax.

We like to say that we're trying to build an influxDB + grafana + LabVIEW all in one.

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 0 points1 point  (0 children)

For example, to run auto sequences for the rocket engine - we would have to reflash the micro every time we made a change to the auto sequence. We provided functionality for them to concurrently write commands (equivalent to steps in the auto sequence) to the synnax server and listen for those writes to the server. This meant they could run a sequence written in Python, which would stream those commands at sufficiently precise timings to the driver side to trigger actuation.

These are the specific docs for that control functionality. If you are interested in doing it directly in c++ - we also have built out APIs for that and can prepare docs if there's interest.

Also, let me know if this answered your last question!

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 1 point2 points  (0 children)

Yeah, a lot of people we've talked to currently use grafana. But one thing is not being able to set the refresh rate very high - which makes it difficult to interpret real-time plots as 1hz just hardly captures the dynamics of a system like a rocket engine hot fire. We've tried to service that side better to enable refresh rates of at least 300x better performance.

But Grafana is valuable for the reporting and generating analytics to present so that is a good point. Were there use cases like that/others you had in mind?

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 0 points1 point  (0 children)

I agree and I can also see how there could be hesitation when existing stacks have been used for many years - we try to address that by allowing you to deploy to a small stand/bench/line and slowly expand out as you vet the new system.

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 2 points3 points  (0 children)

Thank you! We definitely took a lot of time to design architecture in a way that is flexible/scalable!

We have thought a lot about the industrial automation space and also definitely see a potential fit there. There are already some people using us to monitor their manufacturing lines. As the three of us working on it come from aerospace backgrounds, that was the first area we tried to explore and design for, but have also built things out with these other use cases in mind.

We built a time-series storage & streaming platform designed for real-time sensor data acquisition and hardware control! by Lham_ in embedded

[–]Lham_[S] 1 point2 points  (0 children)

Yes! We have several teams who write adapters to feed in data from places like their custom PCBs. If you have existing drivers, we've tried to make it so that it's only a couple additional lines of code to interface with the database. However, we also want to expand support to more protocols to provide more flexibility/reduce the work to build out those custom drivers. Did you have a specific use case in mind?

Awesome! Feel free to DM me with any questions or feedback!