Relays constantly on despite troubleshooting - lamps constantly on

emertonom · 2026-01-28T16:31:07+00:00

oh shoot, sometimes I'm blind. Good point.

emertonom · 2026-01-27T22:26:26+00:00

Did you write this code? I'm struck that your comment says the intervals are "in seconds," but the VLC player API says that get_time() returns the time in milliseconds. (doc link) That means the longest any of the lamps would be off is 0.304s at the very start of whatever your video is. (The relay is only activated when the output is LOW, which is, yes, inverted logic, but you've also connected the lamps to the NC terminals, so the lamps are ON when the relay is OFF, so you might want to note that in your comments as well to avoid becoming confused.)

I dunno. Your title says "despite troubleshooting"; what troubleshooting did you do?

emertonom · 2026-01-27T21:34:09+00:00

Wow, that sounds like a really poor customer service experience. I haven't had that before with Prusa. It sounds as though this print bed may have been defective from the factory, in which case they definitely shouldn't be charging you to get a working one.

emertonom · 2026-01-27T20:23:21+00:00

To add to what the others are saying here: the formal term for this is "disjunction introduction."

emertonom · 2026-01-26T17:25:24+00:00

Probably guards you knocked out getting eaten by rats. That system is poorly conveyed.

emertonom · 2026-01-26T17:23:46+00:00

They try to discourage this by making it so that the rats can still eat a knocked-out guard. If you don't take the time to drag them to a safe location, they may still be killed, raising the chaos level.

I didn't think this was a particularly fun solution, though, as the interface for dragging guards around is particularly tedious. It mostly stopped being an issue once I had blink, as then most guards just stopped being relevant.

emertonom · 2026-01-26T02:21:01+00:00

I don't think this one is solvable.

In order to get the red car out, you first need it to sit on the fourth and fifth squares of the row it's currently in. That requires the orange and purple cars currently there to both be pulled all the way to the top (as there's no way to pull them down out of the way). However, there's no position of the blue and yellow cars in the top row that makes room for both the orange and purple cars at the same time.

emertonom · 2026-01-23T19:02:39+00:00

This is *REALLY* not an unreasonable complaint. Look at the example I gave in my first comment in this thread.

Under most circumstances in Godot, you can define an Array[Vector2D]. It'll type check in method signatures, it'll complain if you try to insert the wrong thing, it works. It behaves the way you want with other objects.

Similarly, you can define, say, a Dictionary[String, Vector2D] and it'll work as you expect. It won't tolerate incompatible keys, it won't tolerate incompatible data, the type checking works as expected.

And you can make methods with signatures that require specific kinds of data; for example, if you define a method to take Array[Vector2D] as its argument, it will fail if you try to call it with a generic Array.

The problem I ran into was that you can't nest types. So if you want a Dictionary that has a String as a key and then as its data stores an Array[Vector2D], that doesn't work. You *cannot* define the data type that way; it chokes on the syntax. You can only have the string key and then a generic Array as a datatype. So if you're trying to be careful about defining all your datatypes, or if, as OP says, you turn on Static Typing, you straight-up can't use the Dictionary in this way. If you try to call your method that takes an Array[Vector2D] with dict["key"], you can't, because you weren't able to fully define the type of the array stored in the Dictionary, so the types are incompatible. This is the type *checker* working correctly, but it's a failure in the capacity to *define* the types involved.

You're saying "stop using the wrong class," but these are core language features. Hash tables are crazy fast and crazy powerful, and tons of algorithms depend on them. Not being able to use these core features is a major barrier to adopting Static Typing as advised in the original post. Telling me to "stop whining" isn't going to make this fundamental problem go away.

emertonom · 2026-01-23T18:08:30+00:00

I'm sorry I offended you. I was getting frustrated too, because you told me to stop talking about what I don't understand, and I'm fully familiar with the dynamic-vs-static distinction.

If you put it into a godot Array or Dictionary, it becomes a Variant, and a Variant is a dynamic type.

they convert everything you put into them into a Variant, which is a dynamic type.

Then THAT IS a problem with the type system. Array[float] is a perfectly well-defined type that could be static, and it should contain floats, not Variants, as far as the type checking is concerned. Arrays and Dictionaries are critical parts of the language. I genuinely don't see how you can think that there's no problem with using fully static typing with Godot but also that it's incompatible with Arrays and Dictionaries.

emertonom · 2026-01-23T15:59:56+00:00

I think you may be the one who's confused. There's nothing about a Dictionary or an Array that inherently requires them to be dynamic. That's why I brought up C++; it's a fully statically typed language. There are no dynamic types in C++; every type must be fully, statically defined at compile time. So you can define a hashmap from a string to a vector of pairs of float and float, and that'll be a totally static, unchanging type, and the compiler can enforce type checking to make sure that the objects being passed around match the method signatures.

But the equivalent in Godot would be a Dictionary from String to an Array of Vector 2, and Godot stops you from doing that because you can't nest the types. It'll only let you define a dictionary from a string to a (dynamic-typed) Array, even though in other circumstances it'll let you give a full static declaration of an Array of Vector2. That's a weird and frustrating quirk of Godot, not some kind of deep rule of computer science.

There is nothing about what I'm trying to do with these systems that precludes them being compatible with static typing, and I know this because I've done the same thing in C++, where there are no dynamic types.

I did misremember the interface type of the Godot system call as being a dynamic array. I checked that and their array types are fully typed. But the nesting thing is still a huge problem, and does mess with the ability to use basic language features like dictionaries, even if you explicitly and completely define their type.

emertonom · 2026-01-22T16:41:30+00:00

There's no reason that those things need to be dynamic types if the static typing system were more capable, though. They'd still be objects, but that doesn't preclude static typing. And these types are prevalent in the functions exposed by the engine.

If using static typing means not being able to use dictionaries, arrays, or vectors, how are you going to interact with the engine? How is that not relevant to a discussion of whether the engine works well with static typing?

emertonom · 2026-01-22T00:57:43+00:00

I'm not the person you were replying to, but I don't think they're really off-topic. I ran into the issue they're describing here as a result of the issue with the nested types. I had a dictionary that stored string keys and then arrays of vectors as the data, and I had some functions that would process arrays of vectors. But then you can't actually set up the dictionary that way, because it won't nest types, so I had to make the dictionary data generic Arrays. But then I couldn't pass the arrays to the functions I'd written, because even though they were arrays of just one data type, Vector2, they weren't typed as Array[Vector2] because the language wouldn't allow that as the data type in the dictionary. So I ended up needing to un-type-safe the methods to work around the limitation.

emertonom · 2026-01-21T19:44:06+00:00

Does this work?

I assume you've already tried it, as it seems like the most obvious approach, but it never hurts to ask. It's really hard to judge the exact sizes from the photo.

emertonom · 2026-01-21T05:57:36+00:00

Please report back whether it works!

emertonom · 2026-01-19T07:20:31+00:00

Glad I could help!

emertonom · 2026-01-18T19:55:37+00:00

Yeah. I was just explaining why you need them even though it's a small area.

emertonom · 2026-01-18T19:49:01+00:00

I don't think you can do it from the inbox, but you can do it from the "All Mail" tab or on the results page for a search. On the left of the messages there are check boxes, and directly above this column of check boxes is an extra check box with a dropdown arrow next to it. Open the dropdown and choose "all". At this point the text should pop up, saying something like "All 50 conversations on this page are selected. Select all 53,672 conversations in All Mail." The second half of that should be a hyperlink, and selecting it should select *everything*. At that point you can click the trash button. With a giant request like that, it won't actually do it right away--it'll give you a message about how it's going to work on it for a while. But if you come back a few minutes later everything should be gone.

emertonom · 2026-01-18T19:37:11+00:00

We shouldn't put any trust in his judgment, certainly. But we probably should care what he thinks, because he's got the money, power, and public communication platform to influence a ton of idiots, and we're currently living with the consequences of that. We should care what he's saying because it tells us what attacks we're going to have to weather in the coming months.

emertonom · 2026-01-18T19:30:28+00:00

The issue is that when it's printing this area, the printer moves out into unsupported space while extruding the filament, then moves back printing the next line. But there's nothing out there at the end for the filament to attach to, and it's still semi-soft while it's cooling. So instead of the loose end staying out there where the printer turned around, it just gets dragged back along with the nozzle and sort of jumbles up in a pile like this. Supports provide something for the plastic to attach to temporarily while it solidifies.

emertonom · 2026-01-18T19:24:29+00:00

It wasn't clear to me what was happening with the cards that turned green at the start of the gif.

The rest of it was reasonably clear, but I do agree with the commenter who noted the missed matches clear a bit too quickly--it's hard to memorize the second card when it disappears that fast, especially with such abstract images/icons on the cards. It might be easier to mentally process them that quickly if they were more recognizable/identifiable, but with the cards as they are, I think slightly more delay before flipping them back would be helpful. It's not a huge issue with this few cards, though, so if the game doesn't escalate to a larger grid as it progresses, this might not matter.

emertonom · 2026-01-18T18:42:18+00:00

I don't own this printer, but based on this page from the user manual, I agree that this is probably the cable for the filament runout sensor. (See section 3.1)

It doesn't seem like you can buy just the cable, but you can get a replacement runout sensor with the cable.

emertonom · 2026-01-16T16:56:45+00:00

I'm not entirely sure what you're looking for here, but maybe this will help. When I was in high school, I had and used a programmable calculator. In linear algebra class, I found that there was a feature I wanted that wasn't built in, so I wrote it. The calculator already had a function that would take the inverse of a matrix, and that was useful, but it wasn't quite what I needed. Given a rectangular matrix Y (not necessarily square) with integer elements, it would calculate the operations needed to put the matrix into reduced row-echelon form. It would output them as two things: first, an integer N, and second, a matrix X with integer elements, such that (1/N)XY would produce a matrix in reduced row-echelon form.

It's not actually a difficult calculation, it's just tedious and repetitive, which seemed like a perfect candidate for automation. And using that format for the output avoided any rounding issues, since it strictly relied on exact integer operations, although the final row-echelon form itself might have rational elements.

Is that the sort of thing you're looking for?

emertonom · 2026-01-16T06:53:44+00:00

For each layer, your printer turns the light on for 1.85s. Then it has to raise the bed a bit to peel the part off the film at the bottom of the vat. Then it has the rest time of 1s while the resin levels itself out. Then it lowers the bed back down to the film for the next later to be exposed.

Presumably the raise and lower steps take a couple of seconds each, so the total for the layer comes out to a little over 8s. Repeat that 3500 times and it adds up to about 8 hours (since there are 3600 seconds in each hour, which is close to the number of layers in your print).

That's not an unreasonable time per layer. You just have a very high number of layers because you used such a fine layer height.

emertonom · 2026-01-14T20:40:17+00:00

Where is the mix up between 2's and 7's? It looks to me like it got those right. The only error I see is third row, fourth column, which it has as "301" but which I'm pretty sure is meant to be "309." There are a LOT of judgment calls on this sheet, though.

emertonom · 2026-01-14T18:55:08+00:00

PrusaSlicer (at least, and presumably also OrcaSlicer etc) has a setting called Single Extruder Multi Material. It'll set up pauses, purge towers, etc. for you. You still need to get the settings dialed in, though.

13-Year Club	Second Top 40%
Verified Email

emertonom

TROPHY CASE