Heat maps in Dashboard instead of Preform?

General Discussion
21

But why take the easy route? Low hanging fruit that alienates a percentage of your customers isn’t low hanging fruit. This leaves all the Form 1 / 1+ users further behind. The resins and dashboard I understand. Yes the architecture was there with the Dashboard for this but come on. If FL discontinued the Form 1+ I could understand the decision to not bother with implementing it within Preform, but last I checked the Form 1+ was still for sale as a new printer purchase.

Maybe if Form X was more active, when will that porcelain resin be released…

22

I really feel like I am missing something. By saying “make use of” and “functionality” you mean viewing them…as in page views?..correct?

23

The printer does have storage, so Dashboard isn’t the only viable solution.

The application doesn’t have to be cloud based to implement cloud-based data capabilities.

The easiest solution isn’t always the best solution. As it is, I probably won’t be using this potentially very useful feature. Why bother doing something if it isn’t done right? I don’t see much advantage as it is now, versus looking at where the clouding is on the tank.

That said, if it is indeed too difficult to generate the heat maps in Preform (I don’t understand why that would be), then it should be quite straightforward for Preform to pull down the heat maps from Dashboard and render them as a texture map. I use networked images all the time, and rendering a texture map in OpenGL is pretty darn simple…

2 Likes
24

IMO, the printer is not a good place to store this data. Memory is a finite resource, and Flash is cheap but not free. FL would not have designed the printer with an excess of storage capacity and much of what they budgeted for is probably the storage of prints. Adding functionality to retain Heatmaps not only requires the storage space for the heat map (and it would need to be an array since you can switch tanks, so the tank could change and then change back later and the printer will need to remember that previous tray), but also additional code space for the user interface so you can manage the storage that’s being consumed at the printer (you’d have to tell the printer it was OK to delete an old tray’s data if you needed to make room for a new tray, though I suppose PreForm could provide the interface and reduce that burden some. But then when you installed a new tray and the printer was out of memory you’d need to walk back to the computer to make room for it).

The cloud on the other hand is, as we all know, of infinite breadth and depth. It effectively has an unlimited storage capacity.

Local storage and display on a PC shouldn’t be all that more difficult to implement than a Cloud. PreForm can talk to the printer, and PreForm can save/retrieve and display data on a PC, so PreForm could presumably handle these Heatmap tasks as well. The problem here is the additional level of complexity required to share the data across the network in environments where there are multiple workstations talking to the same printer. Local storage assumes a particular printer is wedded to a specific workstation.

So here again, I think Cloud wins out. Storage in The Cloud is by its very nature “sharable”.

The downside of course is that access to the functionality is dependent on the Internet and that is an imperfect medium. For most users, though, the Internet is reliable enough this risk represents at most a potential inconvenience. There will be some users, for sure, who have unreliable Internet service and for them I agree, a local storage capability would probably be a plus.

I do agree that it would be a positive addition to functionality if PreForm could pull down and display the Heatmap, at least in the Layout function. That doesn’t seem like it’d be all that big of a challenge. PreForm already uses the Network to talk to the printer. But of course, it’s not zero effort, PreForm engineering resources can’t be unlimited, and we don’t have any idea of any other priorities they need to work. Overall, though, I’m good with the existing implementation. And we know FL definitely pays attention to user feedback from the Forum.

My biggest complaint about the Heatmap function on the Dashboard is that there does not appear to be a way to control playback. I don’t want the thing to play like a looping GIF. I want to step through it and see what’s happening. Also, I may be wrong but it looks like the order prints are playing back in the Heatmap is not the order I printed them in (though it’s possible I started with a print that was very similar to the last print I made, I haven’t been printing a huge amount and this tray has been on the printer for a while).

Also, when I added a new tray, I expected it to show up with an “empty” Heatmap but it doesn’t appear on Dashboard at all. I’m running a print now and I assume it will show up once that print completes…but I’m about 7 hours away from finding out.

25

The space required to store a 300x300 pixel jpeg is 5kb - that is nothing compared to the size files I print to the device. It could store 200 heat maps using only 1 megabyte of storage.

The space needed for a UI would likely also be in the kilo-byte range (rough guess would be 20kb or less).

26

Well, I don’t know that I’d store it as a JPG. JPG compression introduces artifacts that would degrade the image each time it was updated. I’d want it saved uncompressed. So 300x300x8bits is 90KB, which is quite a bit more than 5K.Assuming 8 bits is enough. I’m thinking the laser probably passes over a given point on the tray 10Ks of times before the PDMS wears out so 16 bit resolution might be required. Yeah, you could probably be clever with some kind of lossless compression, but then that adds code which also consumes memory.

And there are other factors to consider. It’s not just a function of how much Flash there is. You can’t run code out of Flash, it’s a serially interfaced device. Primary memory, DRAM, is usually quite a bit more constrained than secondary memory like Flash. Embedded controllers are generally fairly “light weight”. I’d be surprised if the FL’s controller had anywhere near as much DRAM as, say, a typical cell phone. But I’m just guessing.

I’m not sure I agree with the UI estimate but there’s no point in debating it. Truth is, it’s a function of a lot of variables I certainly don’t have any details for, so the best I can do is guess here, too.

27

Using low quality compression (30% of 100% quality), there is absolutely no discernible degradation. In any event, 90KB is a drop in the bucket of the 4GB of on-board flash (and in fact a loseless 8-bit PNG would only require 60kb). But even at 90kb, that means it could track 10 trays (seems like a perfectly reasonable number) with less than 1MB. That is 0.024 of a single percent of the memory - for 10 trays.

There is no reason why data would have to be updated every pass either. It could update the value every 10th or 100th pass (and multiply by 10 or 100 when doing calculations), so I really don’t think 16-bit resolution would be needed.

I really doubt that adding one more text based interface would be the straw that broke the camels back. If that was the case - that means they can’t add any additional functionality to the firmware which seems unlikely to me.

And if that is indeed the case, the heat maps could certainly be managed by Preform.

Well just think about what was capable on the Commodore 64. 64kb was enough to run an entire operating system (took slightly more than half) and software on top in the remaining 30kb of RAM you could run games, music, drawing, etc.

28

@3DTOPO I can see that you feel that this whole thing should be plopped on the machines. So, how do you propose to solve the following problems?

  1. Your business has multiple printers and each machine can/will be used on multiple instances of Preform. What is the step by step process that keeps all of the data on all of the instances of Preform and/or the machines in a group?

  2. You can use materials and trays across the entire system above. How does this fit with the solution above?

The best answer I’ve heard for this at the moment is to put all of the data in one central location (dashboard). Yes, there are issues even with this location but it makes the most sense.

While it would be nice to have the heat map on the base in preform. Even that isn’t an issue if they could lay a grid on the heat map that matches the build platform. It’s not hard to place a part on the platform based on open grids on a map.

29

No, I am just proposing that it is one possibility, and just don’t agree with @Randy_Cohen that there isn’t enough room to store them on the flash drive.

I mentioned in this thread that storing the data in the cloud would be fine, provided Preform had the ability to automatically download and display the heat map.

Well Preform knows which printer it is connected to, and what tray is installed. Preform could simply download the heat map from the printer or Dashboard (wherever it is stored).

To use a single tray in multiple machines, it would need indeed need a centralized data store. I personally think that is a fringe case though and having to use a tray in a single machine to fully take advantage of the heat maps would be an acceptable limitation.

But again, I am not arguing for one location to store the data or another. I just want to see the heat map in Preform, I really don’t care how thats achieved as long as it works.

That would be better than nothing, but still not nearly as nice as it just being displayed in Preform.

30

There are a lot of posts above in regard to storage on the machine. If you have changed that view then great. Implementing a solution that ignores “fringe” problems is exactly how small problems become huge problems. In general we (engineering) test or design out of all known failure modes including “fringe” ones.

31

Ummm, other than me just mentioning that the printer has storage, there are two posts from me about it, but that is only because @Randy_Cohen and I were discussing it.

I’m sorry, but if heat maps where only supported for trays that are used in the same machine I don’t see that as a “huge problem”. I see it as a reasonable limitation for a feature that didn’t even exist a week ago.

1 Like
32

I think a better solution to the heat map is to project the map on the PreForm “surface” or ceiling so that you can rearrange items or alternatively have PreForm be predictive based on the model and show the likely map for the model being printed.

33

yes! i was thinking the same thing to project a heat map back into the cube while laying out the parts, its the same as when your customizing supports and part of the mesh goes red to indicate its not supported well, it would be great to be able to switch to heat map view to see if there’s sections of parts in the layout that are going to be right in the deadzone on a 70% used tank.

I think a color heat map would be better to see which parts of the tank are best to avoid you can kinda see it now where it gets darker than the rest but it still leaves a bit to the imagination as to how far to push that section of tank before it consistently gives crappy deformed / failed results & wastes resin printing there.

i don’t spend a lot of time fiddling about with the display on the machine by the time the models loaded up to go, its just to press some final buttons and kick it off.

Or just fix up tanks so we don’t have to worry too much about wear on them, then the whole heatmap / fiddling about with jiggling things around could be avoided :wink:

1 Like
34

I’d love to use this feature, but I can’t due to Form’s inability to implement a proxy setting in the network settings. You can’t just assume that everyone has access to the dashboard. Especially if you intend for this to be adopted in corporate environments, you need to at least have a basic understanding of how networks operate.

35

The dashboard is just a web page. If you need a Proxy to access the internet from your web browser, that has nothing to do with FL.

Do you mean that your printer can’t access the Internet do send data to the dashboard, because the printer doesn’t implement support for a Proxy in its network setup?

36

@Randy_Cohen if your whole connection runs through a proxy, the printer is unable to connect to the dashboard. We have the same topic currently in our company. If you would be able to adjust the Proxy settings the printer could be connected to the dashboard. Otherwise the whole updating and dashboard stuff won’t work.

1 Like
37

Exactly this! Can’t adjust proxy settings when you have no control over a proxy that sits three states away. I can ask our local IT, but I’m guessing it’s a no.

38

Surely all this requires is the ability to display images in preform.
I have resorted to 2D printing it and holding the page up to the screen :smiley:

1 Like
39

well, i’m not a software developer… but I do have a display that is 23 inches wide… and I just open one window for preform and the dashboard in the other… and eyeball it.

But being a sculptor and product developer- I have a pretty good eyeball.

I don’t think preform needs to store consumables data- its not even 64 bit software- its like asking a volkswagon microbus to haul 15 folks up a steep hill.
Collect and store the info in Dashboard… but its Just a PNG or jpeg… there’s no reason preform can’t download a cumulative map from dashboard for the printer and resin and tank you have selected in Preform.
Or- even auto orient models based upon the saved heatmap in dashboard without having to display anything.

an algorithm that would maximize tank lifetime by orienting successive print models in the most efficient manner would be a nice feature.

40

With the new LT tanks the heat map seems to be redundant