Posts made by gtj0

@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:

Branch	PATH
3.3	${ArmGccPath}:${ArmGccPath_3_3}:...
3.4	${ArmGccPath}:${ArmGccPath_3_4}:...
3.5	${ArmGccPath}:${ArmGccPath_3_5}:...

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

Name	Value
ArmGccPath_3_3	<path to 2020-q4-major
ArmGccPath_3_4	<path to 10.3-2021.10
ArmGccPath_3_5	<path to 12.2>

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.

@Dizzwold said in Linear Rail X Gantry Support (MGN12):

Any alternate suggestions to aluminium plate to support the rail?

Yeah, as @o_lampe said, an aluminum profile would act as a truss and be much stiffer. I use a right angle under my Igus rails.

@Dizzwold said in Linear Rail X Gantry Support (MGN12):

@gtj0 What did you use for the part cooling on Black Beauty. I know from previous conversations that you used fans mounted on the back, then channelled through pipe, but what have you used to direct the airflow onto the printed item, the part covered in Kapton Tape?
It's like a modified mini heat-gun nozzle or something.

That's it exactly. It channels the air right onto the part directly under the nozzle.

@JLM4751 said in Duet 3 and jetson Nano?:

@gtj0 I hate to reply to such an old thread but this is the only one i could find that described the set up of the jetson nano as a SBC with the duet 3.

No worries

First,let's see if the spi device is actually there or not. Try...

# ls -al /dev/spidev*
crw-rw---- 1 root gpio 153, 0 Jun 19 14:55 /dev/spidev0.0
crw-rw---- 1 root gpio 153, 1 Jun 19 14:55 /dev/spidev1.0

If you see the devices then the most probable issue is that the /opt/dsf/conf/config.json file is incorrect. The SPI related stuff should look something like this...

...
  "SpiDevice": "/dev/spidev0.0",
  "SpiBufferSize": 8192,
  "SpiTransferMode": 0,
  "SpiFrequency": 8000000,
  "SpiConnectTimeout": 500,
  "SpiTransferTimeout": 500,
  "SpiConnectionTimeout": 4000,
  "GpioChipDevice": "/dev/gpiochip0",
  "TransferReadyPin": 13,
  "MaxSpiRetries": 3,
...

The waiting for transfer ready timeout error is directly related to the GpioChipDevice and the TransferReadyPin settings.

If you can't get it going, the output of gpiodetect might help.

@gtj0 said in DueUI Compatibility issues with RRF/DSF 3.5:

@stuartofmt said in DueUI Compatibility issues with RRF/DSF 3.5:

@gtj0

Have you release an updated version ?

Oy. I fixed it but then forgot to release it. Another victory for ADHD.

Will get it published today.

Done. Sorry for the delay.