Posts made by gtj0

@T3P3Tony said in WiFiSocketServerRTOS mismatch between project name and repo name:

@gtj0 Thanks. I fixed those links

Thanks Tony!

@dc42 said in WiFiSocketServerRTOS mismatch between project name and repo name:

@gtj0 the repo name does use the capitalised F, see https://github.com/Duet3D/WiFiSocketServerRTOS. Perhaps your local copy uses a lowercase f ?

HA! Yeah your right but I just copied the link from https://github.com/Duet3D/RepRapFirmware/wiki/Building-RepRapFirmware
It looks like the links on that page are wrong...
[WiFiSocketServerRTOS](https://github.com/Duet3D/WifiSocketServerRTOS)

I've been scratching my head trying to figure out why the latest RRF 3.5-dev fails to build with "MessageFormats.h not found" errors. It turns out that the repo (and therefore directory) name is WifiSocketServerRTOS with a lower case f in Wifi however, in the RRF project "C++ General, Paths and Symbols, Includes", the reference to that project directory is WiFiSocketServerRTOS with an upper case F in WiFi. Probably works fine under Windows but won't work under Linux.

@dc42 Changing the repo/directory name isn't really a good idea at this point so can you change the reference in RRF to use the lower case version? That'd still work under Windows.

I can submit a quick PR if you want.

@stuartofmt said in Custom Java Script in config file:

: The default state is state.sensors.probes[0] = null

Interesting. So there is an entry at index 0 but it's null? Can you share the relevant config bits that produce that situation? If it's too complicated, no worries, I'm just curious.

@stuartofmt You've got a couple of issues...

When you were using Array.isArray, you were testing state.sensors.probes[0] and state.sensors.probes[0] which are the elements of the probes array, not arrays themselves so both tests will always return false.

Your second attempt using the global variable will never return 1 because probes, being an array, can't have an array element at index 1 without there being one at 0.

I'm guessing you're using the K parameter on M574 to set the probe number? That value only appears in the state.sensors.endstops object as the probe value. It doesn't control where in either the endstops or probes arrays the probe appears. If you only have 1 probe, that probe will always be state.sensors.probes[0] no matter what you have the K value set to.

If I guessed wrong and you're doing something else, let me know and I'll see if I can help.

I'm going to test it again later today but I think you're going to have to declare getProbeNum as static...

class DueUIConfig {
	static getProbeNum(state) {
		var myprobe = "No Probe";
		if (Array.isArray(state.sensors.probes[0])) {
		

@stuartofmt said in Possible Issue with v3.5.0-beta1:

As a side note, I have noticed that naming the config file xyz.js (instead of xyz.json) makes no difference. Or at least it seems to make no difference.

Now that I think of it, yeah. Originally, I was fetching the config using the old javascript Ajax calls which forbade retrieving code "for security reasons" and required the awful JSONP workarounds. When I did the big refactor a few years ago, I switched to dynamically updating the DOM with a "script" element which caused the browser to just retrieve the config file like any other javascript file. I forgot all about that until I just looked at the code.

@stuartofmt You can indeed include javascript in the config file. It has a suffix of json to get around browser issues but it's actually parsed as a javascript file. In fact, you'll notice that the config is actually wrapped in a class named DueUIConfig. You can add a function to that class or just add it to the top level as a global function, then call it from a ${...} expression elsewhere in the config. In your example, you could create a a function called getProbeNum() that contains the code you posted modified to return the probe number, then call it like ...

"field": "${state.sensors.probes[getProbeNum()].value}"

I thought I had an example of this on the wiki but I don't see it now. I'll have to add it.

@stuartofmt I didn't see your first message, sorry about that. Not sure why. Glad you got it sorted. The reason you were seeing that message repeating as often as you did is because when you're in SBC mode, DueUI is connected to the SBC via a websocket and receiving streaming events. DueUI only goes into polling mode when it's connected directly to a Duet (Standalone mode).

@dc42 Are you going to do this or should I submit a pull request for it?

@Herve_Smith said in Alternative to DWC with R.R.F. ?:

Fluidd

Take a look at DueUI. I wouldn't classify it as "slick" but "slick" is a bit subjective anyway.

https://forum.duet3d.com/category/33/dueui
https://github.com/gtjoseph/DueUI/wiki

@dc42 said in 3.5: Linux build of CrcAppender isn't marked executable:

@gtj0 good idea! What does OsType resolve to on a Mac?

According to org.eclipse.core.runtime.Platform, OsType is one of...

public static final String OS_WIN32 = "win32";
public static final String OS_LINUX = "linux";
public static final String OS_MACOSX = "macosx";

There are others for aix, solaris, hpux, etc but I don't think we care about them

Actually, while we're talking about it, how about also changing CrcAppender in the post-build step that appends the crc to...

`"${workspace_loc:/${ProjName}/Tools/CrcAppender/${OsType}-x86_64/CrcAppender}"

On Linux, ${OsType} resolves to linux.
On Windows, it resolves to win32 (even on 64 bit).
Not sure about macos but it wold be easy enough to find out. Probably macos or osx.

It would require renaming the directories under Tools/CrcAppender but it would remove the need for users to copy the appropriate binary to a directory outside the project that's already in their PATH.

@dc42 Ah, gotcha. I hadn't thought of doing it that way probably because all of my other Eclipse based projects (I've got about 25 of them) use the Eclipse builder to just run make or ninja, etc. on existing build scripts. Since 3.3 is EOL and you're planning to move 3.4 to gcc 12.2 anyway, it'snot really an issue any more. If it becomes one for 3.6 or later versions I can easily do the separate workspace thing as you do.

Thanks!

Since different compilers are now needed for building 3.3, 3.4 and 3.5, can I suggest that each project's build environment for each branch be changed as follows:

Then we can set the following in the workspace-level build environment...

Leaving ${ArmGccPath} at the front of each project's settings keeps things backwards compatible.

@droftarts said in 3.5: Linux build of CrcAppender isn't marked executable:

@gtj0 So set it as an executable? It says to do that in the MacOS instructions, step 3 https://github.com/Duet3D/RepRapFirmware/wiki/Building-RepRapFirmware#instructions-for-building-under-macos

Ian

Well, it was executable in 3.4 and setting it to executable makes a change in the git index so the tree is marked dirty.

...so the final build step fails. Github issue and PR forthcoming.

@fcwilt said in Duet 3 Scanning Z probe:

@gtj0

There is an option to turn off bed heaters during probing.

Reference M558 parameter B

Bn If 1, turn off all heaters while probing, default (B0) leaves heaters on.

Frederick

Ah yeah, I forgot about that. I never used it because probing currently takes long enough that, even with all that mass, the bed cools down a bit during the probe with the heater off. Shouldn't be an issue at this speed though, and de-energized, the wires aren't going to make a difference through 6.5mm of aluminum.

Folks have been talking about magnets but what about a bed heater? I've got a 500x500x6.5mm aluminum bed with a full coverage 1600 watt heater on the bottom and PrintBite on top. As the probe passes over the heater wires, especially if they're energized (not to mention with PWM active), is there going to be an issue? I would think that 6.5mm of aluminum would help to dampen any variance but I'm curious if that was tested.

Hmmm. From the video it looks like the probe has to be mounted "flat" in reference to the bed surface which makes sense but would take up a bit of space. Not that 25mm is a lot but it's "something" . Now if it were a bit bigger, and the center of the coil were open, the hole might be big enough to stick a nozzle through.

Also any limits on the length of the flat FFC cable? My tool platform is very light and I'd prefer not to place the control board on it.